Internet Engineering Task Force (IETF)                          A. Atlas
Request for Comments: 7812                                     C. Bowers
Category: Standards Track                               Juniper Networks
ISSN: 2070-1721                                                G. Enyedi
                                                                Ericsson
                                                               June 2016
        
Internet Engineering Task Force (IETF)                          A. Atlas
Request for Comments: 7812                                     C. Bowers
Category: Standards Track                               Juniper Networks
ISSN: 2070-1721                                                G. Enyedi
                                                                Ericsson
                                                               June 2016
        

An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)

一种基于最大冗余树的IP/LDP快速重路由体系结构(MRT-FRR)

Abstract

摘要

This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure.

本文件定义了使用最大冗余树(MRT-FRR)的IP和LDP快速重路由架构。MRT-FRR是一种技术,在故障后仍然连接的任何网络拓扑中提供100%覆盖率的链路保护和节点保护。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 7841第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7812.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7812.

Copyright Notice

版权公告

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

版权所有(c)2016 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Importance of 100% Coverage . . . . . . . . . . . . . . .   4
     1.2.  Partial Deployment and Backwards Compatibility  . . . . .   5
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . .   7
   5.  MRT and Fast Reroute  . . . . . . . . . . . . . . . . . . . .   9
   6.  Unicast Forwarding with MRT Fast Reroute  . . . . . . . . . .   9
     6.1.  Introduction to MRT Forwarding Options  . . . . . . . . .  10
       6.1.1.  MRT LDP Labels  . . . . . . . . . . . . . . . . . . .  10
         6.1.1.1.  Topology-Scoped FEC Encoded Using a Single Label
                   (Option 1A) . . . . . . . . . . . . . . . . . . .  10
         6.1.1.2.  Topology and FEC Encoded Using a Two-Label Stack
                   (Option 1B) . . . . . . . . . . . . . . . . . . .  11
         6.1.1.3.  Compatibility of MRT LDP Label Options 1A and 1B   12
         6.1.1.4.  Required Support for MRT LDP Label Options  . . .  12
       6.1.2.  MRT IP Tunnels (Options 2A and 2B)  . . . . . . . . .  12
     6.2.  Forwarding LDP Unicast Traffic over MRT Paths . . . . . .  13
       6.2.1.  Forwarding LDP Traffic Using MRT LDP Label Option 1A   13
       6.2.2.  Forwarding LDP Traffic Using MRT LDP Label Option 1B   14
       6.2.3.  Other Considerations for Forwarding LDP Traffic Using
               MRT LDP Labels  . . . . . . . . . . . . . . . . . . .  14
       6.2.4.  Required Support for LDP Traffic  . . . . . . . . . .  14
     6.3.  Forwarding IP Unicast Traffic over MRT Paths  . . . . . .  14
       6.3.1.  Tunneling IP Traffic Using MRT LDP Labels . . . . . .  15
         6.3.1.1.  Tunneling IP Traffic Using MRT LDP Label Option
                   1A  . . . . . . . . . . . . . . . . . . . . . . .  15
         6.3.1.2.  Tunneling IP Traffic Using MRT LDP Label Option
                   1B  . . . . . . . . . . . . . . . . . . . . . . .  15
       6.3.2.  Tunneling IP Traffic Using MRT IP Tunnels . . . . . .  16
       6.3.3.  Required Support for IP Traffic . . . . . . . . . . .  16
   7.  MRT Island Formation  . . . . . . . . . . . . . . . . . . . .  16
     7.1.  IGP Area or Level . . . . . . . . . . . . . . . . . . . .  17
     7.2.  Support for a Specific MRT Profile  . . . . . . . . . . .  17
     7.3.  Excluding Additional Routers and Interfaces from the MRT
           Island  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       7.3.1.  Existing IGP Exclusion Mechanisms . . . . . . . . . .  18
       7.3.2.  MRT-Specific Exclusion Mechanism  . . . . . . . . . .  19
     7.4.  Connectivity  . . . . . . . . . . . . . . . . . . . . . .  19
     7.5.  Algorithm for MRT Island Identification . . . . . . . . .  19
   8.  MRT Profile . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  MRT Profile Options . . . . . . . . . . . . . . . . . . .  19
     8.2.  Router-Specific MRT Parameters  . . . . . . . . . . . . .  21
     8.3.  Default MRT Profile . . . . . . . . . . . . . . . . . . .  21
   9.  LDP Signaling Extensions and Considerations . . . . . . . . .  22
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Importance of 100% Coverage . . . . . . . . . . . . . . .   4
     1.2.  Partial Deployment and Backwards Compatibility  . . . . .   5
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . .   7
   5.  MRT and Fast Reroute  . . . . . . . . . . . . . . . . . . . .   9
   6.  Unicast Forwarding with MRT Fast Reroute  . . . . . . . . . .   9
     6.1.  Introduction to MRT Forwarding Options  . . . . . . . . .  10
       6.1.1.  MRT LDP Labels  . . . . . . . . . . . . . . . . . . .  10
         6.1.1.1.  Topology-Scoped FEC Encoded Using a Single Label
                   (Option 1A) . . . . . . . . . . . . . . . . . . .  10
         6.1.1.2.  Topology and FEC Encoded Using a Two-Label Stack
                   (Option 1B) . . . . . . . . . . . . . . . . . . .  11
         6.1.1.3.  Compatibility of MRT LDP Label Options 1A and 1B   12
         6.1.1.4.  Required Support for MRT LDP Label Options  . . .  12
       6.1.2.  MRT IP Tunnels (Options 2A and 2B)  . . . . . . . . .  12
     6.2.  Forwarding LDP Unicast Traffic over MRT Paths . . . . . .  13
       6.2.1.  Forwarding LDP Traffic Using MRT LDP Label Option 1A   13
       6.2.2.  Forwarding LDP Traffic Using MRT LDP Label Option 1B   14
       6.2.3.  Other Considerations for Forwarding LDP Traffic Using
               MRT LDP Labels  . . . . . . . . . . . . . . . . . . .  14
       6.2.4.  Required Support for LDP Traffic  . . . . . . . . . .  14
     6.3.  Forwarding IP Unicast Traffic over MRT Paths  . . . . . .  14
       6.3.1.  Tunneling IP Traffic Using MRT LDP Labels . . . . . .  15
         6.3.1.1.  Tunneling IP Traffic Using MRT LDP Label Option
                   1A  . . . . . . . . . . . . . . . . . . . . . . .  15
         6.3.1.2.  Tunneling IP Traffic Using MRT LDP Label Option
                   1B  . . . . . . . . . . . . . . . . . . . . . . .  15
       6.3.2.  Tunneling IP Traffic Using MRT IP Tunnels . . . . . .  16
       6.3.3.  Required Support for IP Traffic . . . . . . . . . . .  16
   7.  MRT Island Formation  . . . . . . . . . . . . . . . . . . . .  16
     7.1.  IGP Area or Level . . . . . . . . . . . . . . . . . . . .  17
     7.2.  Support for a Specific MRT Profile  . . . . . . . . . . .  17
     7.3.  Excluding Additional Routers and Interfaces from the MRT
           Island  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       7.3.1.  Existing IGP Exclusion Mechanisms . . . . . . . . . .  18
       7.3.2.  MRT-Specific Exclusion Mechanism  . . . . . . . . . .  19
     7.4.  Connectivity  . . . . . . . . . . . . . . . . . . . . . .  19
     7.5.  Algorithm for MRT Island Identification . . . . . . . . .  19
   8.  MRT Profile . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  MRT Profile Options . . . . . . . . . . . . . . . . . . .  19
     8.2.  Router-Specific MRT Parameters  . . . . . . . . . . . . .  21
     8.3.  Default MRT Profile . . . . . . . . . . . . . . . . . . .  21
   9.  LDP Signaling Extensions and Considerations . . . . . . . . .  22
        
   10. Inter-area Forwarding Behavior  . . . . . . . . . . . . . . .  23
     10.1.  ABR Forwarding Behavior with MRT LDP Label Option 1A . .  23
       10.1.1.  Motivation for Creating the Rainbow-FEC  . . . . . .  24
     10.2.  ABR Forwarding Behavior with IP Tunneling (Option 2) . .  24
     10.3.  ABR Forwarding Behavior with MRT LDP Label Option 1B . .  25
   11. Prefixes Multiply Attached to the MRT Island  . . . . . . . .  26
     11.1.  Protecting Multihomed Prefixes Using Tunnel Endpoint
            Selection  . . . . . . . . . . . . . . . . . . . . . . .  28
     11.2.  Protecting Multihomed Prefixes Using Named Proxy-Nodes .  29
     11.3.  MRT Alternates for Destinations outside the MRT Island .  31
   12. Network Convergence and Preparing for the Next Failure  . . .  32
     12.1.  Micro-loop Prevention and MRTs . . . . . . . . . . . . .  32
     12.2.  MRT Recalculation for the Default MRT Profile  . . . . .  33
   13. Operational Considerations  . . . . . . . . . . . . . . . . .  34
     13.1.  Verifying Forwarding on MRT Paths  . . . . . . . . . . .  34
     13.2.  Traffic Capacity on Backup Paths . . . . . . . . . . . .  34
     13.3.  MRT IP Tunnel Loopback Address Management  . . . . . . .  36
     13.4.  MRT-FRR in a Network with Degraded Connectivity  . . . .  36
     13.5.  Partial Deployment of MRT-FRR in a Network . . . . . . .  37
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  38
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  38
     16.2.  Informative References . . . . . . . . . . . . . . . . .  39
   Appendix A.  Inter-level Forwarding Behavior for IS-IS  . . . . .  41
   Appendix B.  General Issues with Area Abstraction . . . . . . . .  42
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  43
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  43
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  44
        
   10. Inter-area Forwarding Behavior  . . . . . . . . . . . . . . .  23
     10.1.  ABR Forwarding Behavior with MRT LDP Label Option 1A . .  23
       10.1.1.  Motivation for Creating the Rainbow-FEC  . . . . . .  24
     10.2.  ABR Forwarding Behavior with IP Tunneling (Option 2) . .  24
     10.3.  ABR Forwarding Behavior with MRT LDP Label Option 1B . .  25
   11. Prefixes Multiply Attached to the MRT Island  . . . . . . . .  26
     11.1.  Protecting Multihomed Prefixes Using Tunnel Endpoint
            Selection  . . . . . . . . . . . . . . . . . . . . . . .  28
     11.2.  Protecting Multihomed Prefixes Using Named Proxy-Nodes .  29
     11.3.  MRT Alternates for Destinations outside the MRT Island .  31
   12. Network Convergence and Preparing for the Next Failure  . . .  32
     12.1.  Micro-loop Prevention and MRTs . . . . . . . . . . . . .  32
     12.2.  MRT Recalculation for the Default MRT Profile  . . . . .  33
   13. Operational Considerations  . . . . . . . . . . . . . . . . .  34
     13.1.  Verifying Forwarding on MRT Paths  . . . . . . . . . . .  34
     13.2.  Traffic Capacity on Backup Paths . . . . . . . . . . . .  34
     13.3.  MRT IP Tunnel Loopback Address Management  . . . . . . .  36
     13.4.  MRT-FRR in a Network with Degraded Connectivity  . . . .  36
     13.5.  Partial Deployment of MRT-FRR in a Network . . . . . . .  37
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  38
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  38
     16.2.  Informative References . . . . . . . . . . . . . . . . .  39
   Appendix A.  Inter-level Forwarding Behavior for IS-IS  . . . . .  41
   Appendix B.  General Issues with Area Abstraction . . . . . . . .  42
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  43
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  43
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  44
        
1. Introduction
1. 介绍

This document describes a solution for IP/LDP fast reroute [RFC5714]. MRT-FRR creates two alternate forwarding trees that are distinct from the primary next-hop forwarding used during stable operation. These two trees are maximally diverse from each other, providing link and node protection for 100% of paths and failures as long as the failure does not cut the network into multiple pieces. This document defines the architecture for IP/LDP fast reroute with MRT.

本文档描述了IP/LDP快速重路由解决方案[RFC5714]。MRT-FRR创建两个备用转发树,它们不同于稳定运行期间使用的主下一跳转发。这两棵树最大程度上彼此不同,只要故障不会将网络分割成多个部分,就可以为100%的路径和故障提供链路和节点保护。本文件定义了使用MRT进行IP/LDP快速重路由的体系结构。

[RFC7811] describes how to compute maximally redundant trees using a specific algorithm: the MRT Lowpoint algorithm. The MRT Lowpoint algorithm is used by a router that supports the Default MRT Profile, as specified in this document.

[RFC7811]描述了如何使用特定算法计算最大冗余树:MRT低点算法。MRT低点算法由支持本文档中指定的默认MRT配置文件的路由器使用。

IP/LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR) uses two maximally diverse forwarding topologies to provide alternates. A primary next hop should be on only one of the diverse forwarding

使用最大冗余树的IP/LDP快速重路由(MRT-FRR)使用两种最大不同的转发拓扑提供备选方案。主下一个跃点应仅位于不同转发中的一个上

topologies; thus, the other can be used to provide an alternate. Once traffic has been moved to one of the MRTs by one Point of Local Repair (PLR), that traffic is not subject to further repair actions by another PLR, even in the event of multiple simultaneous failures. Therefore, traffic repaired by MRT-FRR will not loop between different PLRs responding to different simultaneous failures.

拓扑结构;因此,另一个可用于提供替代方案。一旦交通被一个本地维修点(PLR)转移到一个MRT,该交通就不会受到另一个PLR的进一步维修行动的影响,即使在多个同时发生故障的情况下也是如此。因此,由MRT-FRR修复的交通不会在响应不同同时故障的不同PLR之间循环。

While MRT provides 100% protection for a single link or node failure, it may not protect traffic in the event of multiple simultaneous failures, nor does it take into account Shared Risk Link Groups (SRLGs). Also, while the MRT Lowpoint algorithm is computationally efficient, it is also new. In order for MRT-FRR to function properly, all of the other nodes in the network that support MRT must correctly compute next hops based on the same algorithm and install the corresponding forwarding state. This is in contrast to other FRR methods where the calculation of backup paths generally involves repeated application of the simpler and widely deployed Shortest Path First (SPF) algorithm, and backup paths themselves reuse the forwarding state used for shortest path forwarding of normal traffic. Section 13 provides operational guidance related to verification of MRT forwarding paths.

虽然MRT为单个链路或节点故障提供100%保护,但它可能不会在多个同时故障的情况下保护流量,也不会考虑共享风险链路组(SRLGs)。此外,虽然MRT低点算法计算效率高,但它也是新的。为了使MRT-FRR正常工作,网络中支持MRT的所有其他节点必须基于相同的算法正确计算下一跳,并安装相应的转发状态。这与其他FRR方法不同,在FRR方法中,备份路径的计算通常涉及重复应用更简单且广泛部署的最短路径优先(SPF)算法,并且备份路径本身重用用于正常流量的最短路径转发的转发状态。第13节提供了与MRT转发路径验证相关的操作指南。

In addition to supporting IP and LDP unicast fast reroute, the diverse forwarding topologies and guarantee of 100% coverage permit fast-reroute technology to be applied to multicast traffic as described in [MRT-ARCH]. However, the current document does not address the multicast applications of MRTs.

除了支持IP和LDP单播快速重路由外,多样化的转发拓扑和100%覆盖率的保证允许将快速重路由技术应用于[MRT-ARCH]中所述的多播流量。然而,当前的文档没有涉及MRT的多播应用。

1.1. Importance of 100% Coverage
1.1. 100%覆盖的重要性

Fast reroute is based upon the single failure assumption: that the time between single failures is long enough for a network to reconverge and start forwarding on the new shortest paths. That does not imply that the network will only experience one failure or change.

快速重路由基于单次故障假设:单次故障之间的时间足够长,网络可以在新的最短路径上重新聚合并开始转发。这并不意味着网络只会经历一次故障或变化。

It is straightforward to analyze a particular network topology for coverage. However, a real network does not always have the same topology. For instance, maintenance events will take links or nodes out of use. Simply costing out a link can have a significant effect on what Loop-Free Alternates (LFAs) are available. Similarly, after a single failure has happened, the topology is changed and its associated coverage has changed as well. Finally, many networks have new routers or links added and removed; each of those changes can have an effect on the coverage for topology-sensitive methods such as LFA and Remote LFA. If fast reroute is important for the network services provided, then a method that guarantees 100% coverage is important to accommodate natural network topology changes.

分析特定网络拓扑的覆盖范围非常简单。然而,实际网络并不总是具有相同的拓扑结构。例如,维护事件将使链接或节点停止使用。简单地计算一个链接的成本就可以对可用的无循环替代(LFA)产生重大影响。类似地,在发生单一故障后,拓扑会发生变化,其相关覆盖范围也会发生变化。最后,许多网络添加和删除了新的路由器或链路;这些变化中的每一个都会对拓扑敏感方法(如LFA和远程LFA)的覆盖范围产生影响。如果快速重路由对于提供的网络服务很重要,那么保证100%覆盖率的方法对于适应自然网络拓扑变化很重要。

When a network needs to use Ordered FIB [RFC6976] or Nearside Tunneling [RFC5715] as a micro-loop prevention mechanism [RFC5715], then the whole IGP area needs to have alternates available. This allows the micro-loop prevention mechanism, which requires slower network convergence, to take the necessary time without adversely impacting traffic. Without complete coverage, traffic to the unprotected destinations will be dropped for significantly longer than with current convergence -- where routers individually converge as fast as possible. See Section 12.1 for more discussion of micro-loop prevention and MRTs.

当网络需要使用有序FIB[RFC6976]或近侧隧道[RFC5715]作为微回路预防机制[RFC5715]时,则整个IGP区域需要有备选方案可用。这使得需要较慢网络收敛的微环预防机制能够在不影响流量的情况下花费必要的时间。在没有完全覆盖的情况下,到未受保护的目的地的流量下降的时间将比当前的融合时间长得多——路由器以尽可能快的速度单独融合。有关微回路预防和MRT的更多讨论,请参见第12.1节。

1.2. Partial Deployment and Backwards Compatibility
1.2. 部分部署和向后兼容性

MRT-FRR supports partial deployment. Routers advertise their ability to support MRT. Inside the MRT-capable connected group of routers (referred to as an MRT Island), the MRTs are computed. Alternates to destinations outside the MRT Island are computed and depend upon the existence of a loop-free neighbor of the MRT Island for that destination. MRT Islands are discussed in detail in Section 7, and partial deployment is discussed in more detail in Section 13.5.

MRT-FRR支持部分部署。路由器宣传其支持捷运的能力。在支持MRT的路由器连接组(称为MRT岛)内,计算MRT。计算地铁岛外目的地的备选方案,并取决于该目的地的地铁岛无环路邻居的存在。第7节详细讨论了MRT岛,第13.5节详细讨论了部分部署。

2. Requirements Language
2. 需求语言

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。

3. Terminology
3. 术语

network graph: A graph that reflects the network topology where all links connect exactly two nodes and broadcast links have been transformed into the standard pseudonode representation.

网络图:反映网络拓扑的图,其中所有链路正好连接两个节点,广播链路已转换为标准伪节点表示。

cut-link: A link whose removal partitions the network. A cut-link by definition must be connected between two cut-vertices. If there are multiple parallel links, then they are referred to as cut-links in this document if removing the set of parallel links would partition the network graph.

切断链路:其删除将网络分割的链路。根据定义,切割链接必须在两个切割顶点之间连接。如果存在多个平行链接,则如果删除平行链接集会分割网络图,则在本文档中它们称为切割链接。

cut-vertex: A vertex whose removal partitions the network graph.

切割顶点:其移除将网络图分割的顶点。

2-connected: A graph that has no cut-vertices. This is a graph that requires two nodes to be removed before the network is partitioned.

2-连通:没有割点的图。这是一个需要在网络分区之前删除两个节点的图。

2-connected cluster: A maximal set of nodes that are 2-connected.

2-连通簇:2-连通的最大节点集。

block: Either a 2-connected cluster, a cut-edge, or a cut-vertex.

块:2连通簇、切割边或切割顶点。

Redundant Trees (RT): A pair of trees where the path from any node X to the root R along the first tree is node-disjoint with the path from the same node X to the root along the second tree. Redundant trees can always be computed in 2-connected graphs.

冗余树(RT):一对树,其中沿第一棵树从任何节点X到根R的路径与沿第二棵树从同一节点X到根的路径不相交。冗余树总是可以在2-连通图中计算。

Maximally Redundant Trees (MRT): A pair of trees where the path from any node X to the root R along the first tree and the path from the same node X to the root along the second tree share the minimum number of nodes and the minimum number of links. Each such shared node is a cut-vertex. Any shared links are cut-links. In graphs that are not 2-connected, it is not possible to compute RTs. However, it is possible to compute MRTs. MRTs are maximally redundant in the sense that they are as redundant as possible given the constraints of the network graph.

最大冗余树(MRT):一对树,其中沿第一棵树从任何节点X到根R的路径以及沿第二棵树从同一节点X到根的路径共享最小节点数和最小链路数。每个这样的共享节点都是一个切割顶点。任何共享链接都是剪切链接。在非2-连通图中,不可能计算RTs。但是,可以计算MRT。MRT是最大冗余的,因为在给定网络图约束的情况下,MRT尽可能冗余。

Directed Acyclic Graph (DAG): A graph where all links are directed and there are no cycles in it.

有向无环图(DAG):一种所有链接都是有向无环的图,其中没有圈。

Almost Directed Acyclic Graph (ADAG): A graph with one node designated as the root. The graph has the property that if all links incoming to the root were removed, then the resulting graph would be a DAG.

几乎有向无环图(ADAG):一个节点指定为根的图。该图的属性是,如果所有传入根的链接都已删除,则生成的图将是DAG。

Generalized ADAG (GADAG): A graph that is the combination of the ADAGs of all blocks.

广义ADAG(GADAG):所有块的ADAG的组合图。

MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used to describe the associated forwarding topology and MPLS Multi-Topology IDentifier (MT-ID). Specifically, MRT-Red is the decreasing MRT where links in the GADAG are taken in the direction from a higher topologically ordered node to a lower one.

捷运红:捷运红用于描述两条捷运中的一条;它用于描述关联的转发拓扑和MPLS多拓扑标识符(MT-ID)。具体地说,MRT Red是递减的MRT,其中GADAG中的链路沿着从较高拓扑顺序节点到较低拓扑顺序节点的方向进行。

MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is used to described the associated forwarding topology and MPLS MT-ID. Specifically, MRT-Blue is the increasing MRT where links in the GADAG are taken in the direction from a lower topologically ordered node to a higher one.

MRT蓝色:MRT蓝色用于描述两个MRT中的一个;它用于描述相关的转发拓扑和MPLS MT-ID。具体而言,MRT Blue是指在GADAG中的链路从较低拓扑顺序的节点向较高拓扑顺序的节点方向移动的不断增加的MRT。

Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the multiple MRT forwarding topologies and to the default forwarding topology. This is referred to as the Rainbow MRT MPLS MT-ID and is used by LDP to reduce signaling and permit the same label to always be advertised to all peers for the same (MT-ID, Prefix).

Rainbow MRT:有一个MPLS MT-ID是很有用的,它引用多个MRT转发拓扑和默认转发拓扑。这被称为Rainbow-MRT-MPLS MT-ID,LDP使用它来减少信令,并允许相同的标签总是为相同的(MT-ID,前缀)向所有对等方通告。

MRT Island: The set of routers that support a particular MRT profile and the links connecting them that support MRT.

MRT岛:支持特定MRT配置文件的路由器集,以及连接它们的链接,支持MRT。

Island Border Router (IBR): A router in the MRT Island that is connected to a router not in the MRT Island, both of which are in a common area or level.

岛边界路由器(IBR):捷运岛上的路由器,与不在捷运岛上的路由器相连,两者都位于公共区域或级别。

Island Neighbor (IN): A router that is not in the MRT Island but is adjacent to an IBR and in the same area/level as the IBR.

孤岛邻居(IN):不在MRT孤岛上但与IBR相邻且与IBR位于同一区域/级别的路由器。

named proxy-node: A proxy-node can represent a destination prefix that can be attached to the MRT Island via at least two routers. It is named if there is a way that traffic can be encapsulated to reach specifically that proxy node; this could be because there is an LDP FEC (Forwarding Equivalence Class) for the associated prefix or because MRT-Red and MRT-Blue IP addresses are advertised in an undefined fashion for that proxy-node.

命名代理节点:代理节点可以表示目标前缀,该前缀可以通过至少两个路由器连接到MRT岛。如果有一种方式可以将流量封装到特定的代理节点,则命名为;这可能是因为相关前缀存在LDP FEC(转发等价类),或者因为MRT Red和MRT Blue IP地址以未定义的方式为该代理节点播发。

4. Maximally Redundant Trees (MRT)
4. 最大冗余树(MRT)

A pair of Maximally Redundant Trees is a pair of directed spanning trees that provides maximally disjoint paths towards their common root. Only links or nodes whose failure would partition the network (i.e., cut-links and cut-vertices) are shared between the trees. The MRT Lowpoint algorithm is given in [RFC7811]. This algorithm can be computed in O(e + n log n); it is less than three SPFs. This document describes how the MRTs can be used and not how to compute them.

一对最大冗余树是一对有向生成树,它向它们的公共根提供最大不相交的路径。树之间仅共享其故障将分割网络的链接或节点(即切割链接和切割顶点)。MRT低点算法在[RFC7811]中给出。该算法可以用O(e+n对数n)计算;它少于三个SPF。本文件描述了如何使用MRT,而不是如何计算MRT。

MRT provides destination-based trees for each destination. Each router stores its normal primary next hop(s) as well as MRT-Blue next hop(s) and MRT-Red next hop(s) toward each destination. The alternate will be selected between the MRT-Blue and MRT-Red.

MRT为每个目的地提供基于目的地的树。每个路由器存储其正常的主下一跳,以及朝向每个目的地的MRT蓝色下一跳和MRT红色下一跳。备选方案将在捷运蓝色和捷运红色之间选择。

The most important thing to understand about MRTs is that for each pair of destination-routed MRTs, there is a path from every node X to the destination D on the Blue MRT that is as disjoint as possible from the path on the Red MRT.

关于MRT,需要了解的最重要的一点是,对于每对目的地路由MRT,在蓝色MRT上有一条从每个节点X到目的地D的路径,该路径与红色MRT上的路径尽可能不相交。

For example, in Figure 1, there is a network graph that is 2-connected in (a) and associated MRTs in (b) and (c). One can consider the paths from B to R; on the Blue MRT, the paths are B->F->D->E->R or B->C->D->E->R. On the Red MRT, the path is B->A->R. These are clearly link and node-disjoint. These MRTs are redundant trees because the paths are disjoint.

例如,在图1中,有一个网络图在(a)中是2连通的,在(b)和(c)中是相关的MRT。可以考虑从B到R的路径;在蓝色捷运上,路径是B->F->D->E->R或B->C->D->E->R。在红色捷运上,路径是B->A->R。这些路径明显是链接和节点不相交的。这些MRT是冗余树,因为路径是不相交的。

   [E]---[D]---|           [E]<--[D]<--|                [E]-->[D]---|
    |     |    |            |     ^    |                       |    |
    |     |    |            V     |    |                       V    V
   [R]   [F]  [C]          [R]   [F]  [C]               [R]   [F]  [C]
    |     |    |                  ^    ^                 ^     |    |
    |     |    |                  |    |                 |     V    |
   [A]---[B]---|           [A]-->[B]---|                [A]<--[B]<--|
        
   [E]---[D]---|           [E]<--[D]<--|                [E]-->[D]---|
    |     |    |            |     ^    |                       |    |
    |     |    |            V     |    |                       V    V
   [R]   [F]  [C]          [R]   [F]  [C]               [R]   [F]  [C]
    |     |    |                  ^    ^                 ^     |    |
    |     |    |                  |    |                 |     V    |
   [A]---[B]---|           [A]-->[B]---|                [A]<--[B]<--|
        

(a) (b) (c) a 2-connected graph Blue MRT towards R Red MRT towards R

(a) (b)(c)一个2连通图,蓝色地铁走向R,红色地铁走向R

Figure 1: A 2-Connected Network

图1:一个2连接的网络

By contrast, in Figure 2, the network in (a) is not 2-connected. If C, G, or the link C<->G failed, then the network would be partitioned. It is clearly impossible to have two link-disjoint or node-disjoint paths from G, J, or H to R. The MRTs given in (b) and (c) offer paths that are as disjoint as possible. For instance, the paths from B to R are the same as in Figure 1 and the path from G to R on the Blue MRT is G->C->D->E->R and on the Red MRT is G->C->B->A->R.

相比之下,在图2中,(a)中的网络不是2-连接的。如果C、G或链路C<->G出现故障,则网络将被分区。显然,从G、J或H到R的两条链路不相交或节点不相交的路径是不可能的。在(b)和(c)中给出的MRT提供了尽可能不相交的路径。例如,从B到R的路径与图1相同,在蓝色地铁上从G到R的路径是G->C->D->E->R,在红色地铁上是G->C->B->A->R。

                        [E]---[D]---|     |---[J]
                         |     |    |     |    |
                         |     |    |     |    |
                        [R]   [F]  [C]---[G]   |
                         |     |    |     |    |
                         |     |    |     |    |
                        [A]---[B]---|     |---[H]
        
                        [E]---[D]---|     |---[J]
                         |     |    |     |    |
                         |     |    |     |    |
                        [R]   [F]  [C]---[G]   |
                         |     |    |     |    |
                         |     |    |     |    |
                        [A]---[B]---|     |---[H]
        

(a) a graph that is not 2-connected

(a) 非二连通图

         [E]<--[D]<--|         [J]        [E]-->[D]---|     |---[J]
          |     ^    |          |                |    |     |    ^
          V     |    |          |                V    V     V    |
         [R]   [F]  [C]<--[G]   |         [R]   [F]  [C]<--[G]   |
                ^    ^     ^    |          ^     |    |          |
                |    |     |    V          |     V    |          |
         [A]-->[B]---|     |---[H]        [A]<--[B]<--|         [H]
        
         [E]<--[D]<--|         [J]        [E]-->[D]---|     |---[J]
          |     ^    |          |                |    |     |    ^
          V     |    |          |                V    V     V    |
         [R]   [F]  [C]<--[G]   |         [R]   [F]  [C]<--[G]   |
                ^    ^     ^    |          ^     |    |          |
                |    |     |    V          |     V    |          |
         [A]-->[B]---|     |---[H]        [A]<--[B]<--|         [H]
        

(b) Blue MRT towards R (c) Red MRT towards R

(b) 蓝色地铁驶往R(c)红色地铁驶往R

Figure 2: A Network That Is Not 2-Connected

图2:非双向连接的网络

5. MRT and Fast Reroute
5. 捷运与快速改道

In normal IGP routing, each router has its Shortest Path Tree (SPT) to all destinations. From the perspective of a particular destination, D, this looks like a reverse SPT (rSPT). To use MRT, in addition, each destination D has two MRTs associated with it; by convention these will be called the MRT-Blue and MRT-Red. MRT-FRR is realized by using multi-topology forwarding. There is a MRT-Blue forwarding topology and a MRT-Red forwarding topology.

在正常的IGP路由中,每个路由器都有到所有目的地的最短路径树(SPT)。从特定目的地D的角度来看,这看起来像一个反向SPT(rSPT)。使用捷运,另外,每个目的地D有两个与之相关联的捷运;按照惯例,这些将被称为捷运蓝和捷运红。MRT-FRR采用多拓扑转发实现。存在MRT蓝色转发拓扑和MRT红色转发拓扑。

Any IP/LDP fast-reroute technique beyond LFA requires an additional dataplane procedure, such as an additional forwarding mechanism. The well-known options are multi-topology forwarding (used by MRT-FRR), tunneling (e.g., [RFC6981] or [RFC7490]), and per-interface forwarding (e.g., Loop-Free Failure Insensitive Routing in [EnyediThesis]).

LFA之外的任何IP/LDP快速重路由技术都需要额外的数据平面过程,例如额外的转发机制。众所周知的选项有多拓扑转发(MRT-FRR使用)、隧道(例如[RFC6981]或[RFC7490])和每接口转发(例如[EnyediThesis]中的无环路故障不敏感路由)。

When there is a link or node failure affecting, but not partitioning, the network, each node will still have at least one path via one of the MRTs to reach the destination D. For example, in Figure 2, B would normally forward traffic to R across the path B->A->R. If the B<->A link fails, then B could use the MRT-Blue path B->F->D->E->R.

当链路或节点故障影响(但不影响分区)网络时,每个节点仍将至少有一条路径通过一个MRT到达目的地D。例如,在图2中,B通常会通过路径B->a->R将流量转发到R。如果B<->a链路故障,则B可以使用MRT蓝色路径B->F->D->E->R。

As is always the case with fast-reroute technologies, forwarding does not change until a local failure is detected. Packets are forwarded along the shortest path. The appropriate alternate to use is pre-computed. [RFC7811] describes exactly how to determine whether the MRT-Blue next hops or the MRT-Red next hops should be the MRT alternate next hops for a particular primary next hop to a particular destination.

与快速重路由技术的情况一样,在检测到本地故障之前,转发不会改变。数据包沿着最短路径转发。要使用的适当替代方案是预先计算的。[RFC7811]准确地描述了如何确定MRT蓝色下一跳或MRT红色下一跳是否应该是到特定目的地的特定主下一跳的MRT备用下一跳。

MRT alternates are always available to use. It is a local decision whether to use an MRT alternate, an LFA, or some other type of alternate.

捷运候补列车始终可用。是否使用捷运候补、LFA或其他类型的候补是当地的决定。

As described in [RFC5286], when a worse failure than is anticipated happens, using LFAs that are not downstream neighbors can cause looping among alternates. Section 1.1 of [RFC5286] gives an example of link-protecting alternates causing a loop on node failure. Even if a worse failure than anticipated happens, the use of MRT alternates will not cause looping.

如[RFC5286]中所述,当发生比预期更严重的故障时,使用不是下游邻居的LFA可能会导致备选方案之间的循环。[RFC5286]的第1.1节给出了导致节点上环路故障的链路保护备选方案的示例。即使发生比预期更严重的故障,使用MRT替代方案也不会导致循环。

6. Unicast Forwarding with MRT Fast Reroute
6. 具有MRT快速重路由的单播转发

There are three possible types of routers involved in forwarding a packet along an MRT path. At the MRT ingress router, the packet leaves the shortest path to the destination and follows an MRT path to the destination. In an FRR application, the MRT ingress router is

沿MRT路径转发数据包可能涉及三种类型的路由器。在MRT入口路由器,数据包离开到目的地的最短路径,并沿着MRT路径到达目的地。在FRR应用中,MRT入口路由器是

the PLR. An MRT transit router takes a packet that arrives already associated with the particular MRT, and forwards it on that same MRT. In some situations (to be discussed later), the packet will need to leave the MRT path and return to the shortest path. This takes place at the MRT egress router. The MRT ingress and egress functionality may depend on the underlying type of packet being forwarded (LDP or IP). The MRT transit functionality is independent of the type of packet being forwarded. We first consider several MRT transit forwarding mechanisms. Then, we look at how these forwarding mechanisms can be applied to carrying LDP and IP traffic.

PLR。捷运中转路由器接收已经到达的与特定捷运相关联的数据包,并在同一捷运上转发。在某些情况下(稍后讨论),数据包将需要离开MRT路径并返回到最短路径。这发生在捷运出口路由器。MRT入口和出口功能可能取决于转发的分组的基本类型(LDP或IP)。MRT传输功能与转发的数据包类型无关。我们首先考虑几种MRT转接转发机制。然后,我们将研究如何将这些转发机制应用于承载LDP和IP流量。

6.1. Introduction to MRT Forwarding Options
6.1. 捷运转发选项简介

The following options for MRT forwarding mechanisms are considered.

考虑以下MRT转发机制的选项。

1. MRT LDP Labels

1. 捷运LDP标签

A. Topology-scoped FEC encoded using a single label

A.使用单个标签编码的拓扑范围FEC

B. Topology and FEC encoded using a two-label stack

B.使用双标签堆栈编码的拓扑和FEC

2. MRT IP Tunnels

2. 地铁IP隧道

A. MRT IPv4 Tunnels

甲.地铁隧道

B. MRT IPv6 Tunnels

B.地铁IPv6隧道

6.1.1. MRT LDP Labels
6.1.1. 捷运LDP标签

We consider two options for the MRT forwarding mechanisms using MRT LDP labels.

我们考虑使用MRT LDP标签的MRT转发机制的两种选择。

6.1.1.1. Topology-Scoped FEC Encoded Using a Single Label (Option 1A)
6.1.1.1. 使用单个标签编码的拓扑范围FEC(选项1A)

[RFC7307] provides a mechanism to distribute FEC-label bindings scoped to a given MPLS topology (represented by MPLS MT-ID). To use multi-topology LDP to create MRT forwarding topologies, we associate two MPLS MT-IDs with the MRT-Red and MRT-Blue forwarding topologies, in addition to the default shortest path forwarding topology with MT-ID=0.

[RFC7307]提供了一种机制,用于分发作用域为给定MPLS拓扑(由MPLS MT-ID表示)的FEC标签绑定。为了使用多拓扑LDP创建MRT转发拓扑,我们将两个MPLS MT ID与MRT Red和MRT Blue转发拓扑相关联,以及MT-ID=0的默认最短路径转发拓扑。

With this forwarding mechanism, a single label is distributed for each topology-scoped FEC. For a given FEC in the default topology (call it default-FEC-A), two additional topology-scoped FECs would be created, corresponding to the Red and Blue MRT forwarding topologies (call them red-FEC-A and blue-FEC-A). A router supporting this MRT transit forwarding mechanism advertises a different FEC-label binding for each of the three topology-scoped FECs. When a packet is

通过这种转发机制,为每个拓扑范围的FEC分配一个标签。对于默认拓扑(称为default-FEC-a)中的给定FEC,将创建两个额外的拓扑范围FEC,对应于红色和蓝色MRT转发拓扑(称为Red-FEC-a和Blue-FEC-a)。支持此MRT传输转发机制的路由器为三个拓扑范围的FEC中的每一个播发不同的FEC标签绑定。当一个包

received with a label corresponding to red-FEC-A (for example), an MRT transit router will determine the next hop for the MRT-Red forwarding topology for that FEC, swap the incoming label with the outgoing label corresponding to red-FEC-A learned from the MRT-Red next-hop router, and forward the packet.

通过与red-FEC-a对应的标签接收(例如),MRT中转路由器将确定该FEC的MRT red转发拓扑的下一跳,将传入标签与从MRT red next hop路由器获悉的与red-FEC-a对应的传出标签交换,并转发分组。

This forwarding mechanism has the useful property that the FEC associated with the packet is maintained in the labels at each hop along the MRT. We will take advantage of this property when specifying how to carry LDP traffic on MRT paths using multi-topology LDP labels.

该转发机制具有有用的特性,即与分组相关联的FEC在沿MRT的每个跃点的标签中维护。在指定如何使用多拓扑LDP标签在MRT路径上承载LDP流量时,我们将利用此属性。

This approach is very simple for hardware to support. However, it reduces the label space for other uses, and it increases the memory needed to store the labels and the communication required by LDP to distribute FEC-label bindings. In general, this approach will also increase the time needed to install the FRR entries in the Forwarding Information Base (FIB) and, hence, the time needed before the next failure can be protected.

这种方法对于硬件支持来说非常简单。但是,它减少了用于其他用途的标签空间,并增加了存储标签所需的内存以及LDP分发FEC标签绑定所需的通信。通常,这种方法还将增加在转发信息库(FIB)中安装FRR条目所需的时间,因此,在下一次故障得到保护之前所需的时间。

This forwarding option uses the LDP signaling extensions described in [RFC7307]. The MRT-specific LDP extensions required to support this option will be described elsewhere.

此转发选项使用[RFC7307]中描述的LDP信令扩展。支持此选项所需的MRT特定LDP扩展将在其他地方描述。

6.1.1.2. Topology and FEC Encoded Using a Two-Label Stack (Option 1B)
6.1.1.2. 拓扑和FEC使用双标签堆栈编码(选项1B)

With this forwarding mechanism, a two-label stack is used to encode the topology and the FEC of the packet. The top label (topology-id label) identifies the MRT forwarding topology, while the second label (FEC label) identifies the FEC. The top label would be a new FEC type with two values corresponding to MRT Red and Blue topologies.

通过这种转发机制,使用两个标签堆栈对数据包的拓扑和FEC进行编码。顶部标签(拓扑id标签)标识MRT转发拓扑,而第二个标签(FEC标签)标识FEC。顶部标签将是一个新的FEC类型,有两个值对应于MRT红色和蓝色拓扑。

When an MRT transit router receives a packet with a topology-id label, the router pops the top label and uses that it to guide the next-hop selection in combination with the next label in the stack (the FEC label). The router then swaps the FEC label, using the FEC-label bindings learned through normal LDP mechanisms. The router then pushes the topology-id label for the next hop.

当MRT中转路由器接收到带有拓扑id标签的数据包时,路由器弹出顶部标签,并使用该标签与堆栈中的下一个标签(FEC标签)一起指导下一跳选择。路由器然后交换FEC标签,使用通过正常LDP机制学习的FEC标签绑定。路由器然后为下一跳推送拓扑id标签。

As with Option 1A, this forwarding mechanism also has the useful property that the FEC associated with the packet is maintained in the labels at each hop along the MRT.

与选项1A一样,该转发机制还具有有用的特性,即与分组相关联的FEC保持在沿MRT的每个跃点的标签中。

This forwarding mechanism has minimal usage of additional labels, memory and LDP communication. It does increase the size of packets and the complexity of the required label operations and lookups.

这种转发机制对附加标签、内存和LDP通信的使用最少。它确实增加了数据包的大小以及所需标签操作和查找的复杂性。

This forwarding option is consistent with context-specific label spaces, as described in [RFC5331]. However, the precise LDP behavior required to support this option for MRT has not been specified.

此转发选项与上下文特定的标签空间一致,如[RFC5331]中所述。但是,尚未指定支持MRT此选项所需的精确LDP行为。

6.1.1.3. Compatibility of MRT LDP Label Options 1A and 1B
6.1.1.3. MRT LDP标签选项1A和1B的兼容性

MRT transit forwarding based on MRT LDP Label options 1A and 1B can coexist in the same network, with a packet being forwarded along a single MRT path using the single label of Option 1A for some hops and the two-label stack of Option 1B for other hops. However, to simplify the process of MRT Island formation, we require that all routers in the MRT Island support at least one common forwarding mechanism. As an example, the Default MRT Profile requires support for the MRT LDP Label Option 1A forwarding mechanism. This ensures that the routers in an MRT island supporting the Default MRT Profile will be able to establish MRT forwarding paths based on MRT LDP Label Option 1A. However, an implementation supporting Option 1A may also support Option 1B. If the scaling or performance characteristics for the two options differ in this implementation, then it may be desirable for a pair of adjacent routers to use Option 1B labels instead of the Option 1A labels. If those routers successfully negotiate the use of Option 1B labels, they are free to use them. This can occur without any of the other routers in the MRT Island being made aware of it.

基于MRT LDP标签选项1A和1B的MRT中转转发可以在同一网络中共存,对于某些跳,使用选项1A的单个标签沿着单个MRT路径转发数据包,对于其他跳,使用选项1B的两个标签堆栈。然而,为了简化MRT岛的形成过程,我们要求MRT岛中的所有路由器至少支持一种公共转发机制。例如,默认MRT配置文件要求支持MRT LDP标签选项1A转发机制。这确保了支持默认MRT配置文件的MRT岛中的路由器能够基于MRT LDP标签选项1A建立MRT转发路径。然而,支持选项1A的实现也可以支持选项1B。如果两个选项的缩放或性能特征在此实现中不同,则可能希望一对相邻路由器使用选项1B标签而不是选项1A标签。如果这些路由器成功协商选择1B标签的使用,他们可以自由使用。这可以在MRT岛上的任何其他路由器都不知道的情况下发生。

Note that this document only defines the Default MRT Profile, which requires support for the MRT LDP Label Option 1A forwarding mechanism.

请注意,本文档仅定义了默认的MRT配置文件,它要求支持MRT LDP标签选项1A转发机制。

6.1.1.4. Required Support for MRT LDP Label Options
6.1.1.4. MRT LDP标签选项所需的支持

If a router supports a profile that includes the MRT LDP Label Option 1A for the MRT transit forwarding mechanism, then it MUST support Option 1A, which encodes topology-scoped FECs using a single label. The router MAY also support Option 1B.

如果路由器支持包含MRT传输转发机制的MRT LDP标签选项1A的配置文件,那么它必须支持选项1A,该选项使用单个标签对拓扑范围的FEC进行编码。路由器也可以支持选项1B。

If a router supports a profile that includes the MRT LDP Label Option 1B for the MRT transit forwarding mechanism, then it MUST support Option 1B, which encodes the topology and FEC using a two-label stack. The router MAY also support Option 1A.

如果路由器支持包含MRT传输转发机制的MRT LDP标签选项1B的配置文件,那么它必须支持选项1B,该选项使用双标签堆栈对拓扑和FEC进行编码。路由器也可以支持选项1A。

6.1.2. MRT IP Tunnels (Options 2A and 2B)
6.1.2. 地铁IP隧道(方案2A和2B)

IP tunneling can also be used as an MRT transit forwarding mechanism. Each router supporting this MRT transit forwarding mechanism announces two additional loopback addresses and their associated MRT color. Those addresses are used as destination addresses for MRT-blue and MRT-red IP tunnels, respectively. The special loopback

IP隧道也可以用作MRT传输转发机制。支持此MRT传输转发机制的每个路由器宣布两个额外的环回地址及其相关的MRT颜色。这些地址分别用作MRT蓝色和MRT红色IP隧道的目标地址。特殊环回

addresses allow the transit nodes to identify the traffic as being forwarded along either the MRT-blue or MRT-red topology to reach the tunnel destination. For example, an MRT ingress router can cause a packet to be tunneled along the MRT-red path to router X by encapsulating the packet using the MRT-red loopback address advertised by router X. Upon receiving the packet, router X would remove the encapsulation header and forward the packet based on the original destination address.

地址允许传输节点识别沿MRT蓝色或MRT红色拓扑转发的流量,以到达隧道目的地。例如,MRT入口路由器可以通过使用路由器X公布的MRT red环回地址封装数据包,从而使数据包沿着MRT red路径被隧道传输到路由器X。在收到数据包后,路由器X将移除封装头并基于原始目的地地址转发数据包。

Either IPv4 (Option 2A) or IPv6 (Option 2B) can be used as the tunneling mechanism.

IPv4(选项2A)或IPv6(选项2B)都可以用作隧道机制。

Note that the two forwarding mechanisms using LDP Label options do not require additional loopbacks per router, as is required by the IP tunneling mechanism. This is because LDP labels are used on a hop-by-hop basis to identify MRT-blue and MRT-red forwarding topologies.

请注意,使用LDP标签选项的两种转发机制不需要每个路由器额外的环回,正如IP隧道机制所要求的那样。这是因为LDP标签在逐跳的基础上用于识别MRT blue和MRT red转发拓扑。

6.2. Forwarding LDP Unicast Traffic over MRT Paths
6.2. 在MRT路径上转发LDP单播业务

In the previous section, we examined several options for providing MRT transit forwarding functionality, which is independent of the type of traffic being carried. We now look at the MRT ingress functionality, which will depend on the type of traffic being carried (IP or LDP). We start by considering LDP traffic.

在上一节中,我们研究了几个提供捷运中转功能的选项,这些选项与所承载的交通类型无关。现在我们来看一下MRT入口功能,它将取决于所承载的流量类型(IP或LDP)。我们首先考虑LDP流量。

We also simplify the initial discussion by assuming that the network consists of a single IGP area, and that all routers in the network participate in MRT. Other deployment scenarios that require MRT egress functionality are considered later in this document.

我们还简化了最初的讨论,假设网络由单个IGP区域组成,并且网络中的所有路由器都参与MRT。本文档后面将考虑需要MRT出口功能的其他部署场景。

In principle, it is possible to carry LDP traffic in MRT IP tunnels. However, for LDP traffic, it is desirable to avoid tunneling. Tunneling LDP traffic to a remote node requires knowledge of remote FEC-label bindings so that the LDP traffic can continue to be forwarded properly when it leaves the tunnel. This requires targeted LDP sessions, which can add management complexity. As described below, the two MRT forwarding mechanisms that use LDP labels do not require targeted LDP sessions.

原则上,可以在MRT IP隧道中承载LDP业务。然而,对于LDP业务,最好避免隧道。通过隧道将LDP流量传输到远程节点需要了解远程FEC标签绑定,以便LDP流量在离开隧道时可以继续正确转发。这需要有针对性的LDP会话,这会增加管理复杂性。如下所述,使用LDP标签的两种MRT转发机制不需要目标LDP会话。

6.2.1. Forwarding LDP Traffic Using MRT LDP Label Option 1A
6.2.1. 使用MRT LDP标签选项1A转发LDP流量

The MRT LDP Label Option 1A forwarding mechanism uses topology-scoped FECs encoded using a single label as described in Section 6.1.1.1. When a PLR receives an LDP packet that needs to be forwarded on the MRT-Red (for example), it does a label swap operation, replacing the usual LDP label for the FEC with the MRT-Red label for that FEC received from the next-hop router in the MRT-Red computed by the PLR. When the next-hop router in the MRT-Red receives the packet with the

MRT LDP标签选项1A转发机制使用第6.1.1节所述的使用单个标签编码的拓扑范围FEC。当PLR接收到需要在MRT Red(例如)上转发的LDP分组时,它执行标签交换操作,将FEC的常用LDP标签替换为从下一跳路由器接收到的FEC的MRT Red标签,该标签由PLR计算为MRT Red。当MRT Red中的下一跳路由器接收到带有

MRT-Red label for the FEC, the MRT transit forwarding functionality continues as described in Section 6.1.1.1. In this way, the original FEC associated with the packet is maintained at each hop along the MRT.

MRT红色标签对于FEC,MRT中转转发功能将按照第6.1.1.1节所述继续。这样,与分组相关联的原始FEC在沿MRT的每个跃点处被维持。

6.2.2. Forwarding LDP Traffic Using MRT LDP Label Option 1B
6.2.2. 使用MRT LDP标签选项1B转发LDP流量

The MRT LDP Label Option 1B forwarding mechanism encodes the topology and the FEC using a two-label stack as described in Section 6.1.1.2. When a PLR receives an LDP packet that needs to be forwarded on the MRT-Red, it first does a normal LDP label swap operation, replacing the incoming normal LDP label associated with a given FEC with the outgoing normal LDP label for that FEC learned from the next hop on the MRT-Red. In addition, the PLR pushes the topology-id label associated with the MRT-Red, and forward the packet to the appropriate next hop on the MRT-Red. When the next-hop router in the MRT-Red receives the packet with the MRT-Red label for the FEC, the MRT transit forwarding functionality continues as described in Section 6.1.1.2. As with Option 1A, the original FEC associated with the packet is maintained at each hop along the MRT.

MRT LDP标签选项1B转发机制使用第6.1.1.2节所述的双标签堆栈对拓扑和FEC进行编码。当PLR接收到需要在MRT Red上转发的LDP分组时,它首先执行正常LDP标签交换操作,用从MRT Red上的下一跳学习到的FEC的传出正常LDP标签替换与给定FEC相关联的传入正常LDP标签。此外,PLR推送与MRT Red相关联的拓扑id标签,并将数据包转发到MRT Red上的适当下一跳。当MRT Red中的下一跳路由器接收到FEC带有MRT Red标签的数据包时,MRT传输转发功能将继续,如第6.1.1.2节所述。与选项1A一样,与分组相关联的原始FEC在沿MRT的每个跃点处保持。

6.2.3. Other Considerations for Forwarding LDP Traffic Using MRT LDP Labels

6.2.3. 使用MRT LDP标签转发LDP流量的其他注意事项

Note that forwarding LDP traffic using MRT LDP Labels can be done without the use of targeted LDP sessions when an MRT path to the destination FEC is used. The alternates selected in [RFC7811] use the MRT path to the destination FEC, so targeted LDP sessions are not needed. If instead one found it desirable to have the PLR use an MRT to reach the primary next-next-hop for the FEC, and then continue forwarding the LDP packet along the shortest path from the primary next-next-hop, this would require tunneling to the primary next-next-hop and a targeted LDP session for the PLR to learn the FEC-label binding for primary next-next-hop to correctly forward the packet.

注意,当使用到目的地FEC的MRT路径时,使用MRT-LDP标签转发LDP流量可以在不使用目标LDP会话的情况下完成。[RFC7811]中选择的备选方案使用到目标FEC的MRT路径,因此不需要目标LDP会话。相反,如果发现希望PLR使用MRT到达FEC的主下一跳,然后继续沿着来自主下一跳的最短路径转发LDP分组,这将需要到主下一跳的隧道和PLR的目标LDP会话来学习主下一跳的FEC标签绑定,以正确转发数据包。

6.2.4. Required Support for LDP Traffic
6.2.4. LDP通信所需的支持

For greatest hardware compatibility, routers implementing MRT fast reroute of LDP traffic MUST support Option 1A of encoding the MT-ID in the labels (See Section 9).

为了实现最大的硬件兼容性,实现LDP流量MRT快速重路由的路由器必须支持在标签中编码MT-ID的选项1A(参见第9节)。

6.3. Forwarding IP Unicast Traffic over MRT Paths
6.3. 通过MRT路径转发IP单播流量

For IPv4 traffic, there is no currently practical alternative except tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red forwarding topology. For IPv6 traffic, in principle, one could define bits in the IPv6 options header to indicate the MRT-Blue or MRT-Red forwarding topology. However, in this document, we have

对于IPv4流量,除了通过隧道来获取指示MRT蓝色或MRT红色转发拓扑所需的位之外,目前没有其他可行的选择。原则上,对于IPv6流量,可以在IPv6选项标头中定义位,以指示MRT蓝色或MRT红色转发拓扑。然而,在这份文件中,我们有

chosen not to define a solution that would work for IPv6 traffic but not for IPv4 traffic.

选择不定义适用于IPv6流量但不适用于IPv4流量的解决方案。

The choice of tunnel egress is flexible since any router closer to the destination than the next hop can work. This architecture assumes that the original destination in the area is selected (see Section 11 for handling of multihomed prefixes); another possible choice is the next-next-hop towards the destination. As discussed in the previous section, for LDP traffic, using the MRT to the original destination simplifies MRT-FRR by avoiding the need for targeted LDP sessions to the next-next-hop. For IP, that consideration doesn't apply.

隧道出口的选择是灵活的,因为任何比下一跳更接近目的地的路由器都可以工作。该体系结构假设选择了该区域中的原始目的地(有关多址前缀的处理,请参见第11节);另一个可能的选择是前往目的地的下一跳。如前一节所讨论的,对于LDP流量,使用到原始目的地的MRT简化了MRT-FRR,因为不需要到下一跳的目标LDP会话。对于知识产权,这一考虑不适用。

Some situations require tunneling IP traffic along an MRT to a tunnel endpoint that is not the destination of the IP traffic. These situations will be discussed in detail later. We note here that an IP packet with a destination in a different IGP area/level from the PLR should be tunneled on the MRT to the Area Border Router (ABR) or Level Border Router (LBR) on the shortest path to the destination. For a destination outside of the PLR's MRT Island, the packet should be tunneled on the MRT to a non-proxy-node immediately before the named proxy-node on that particular color MRT.

某些情况需要沿MRT将IP流量隧道至不是IP流量目的地的隧道端点。这些情况将在后面详细讨论。我们在此注意到,目的地与PLR位于不同IGP区域/级别的IP数据包应在MRT上以最短路径通过隧道传输到区域边界路由器(ABR)或级别边界路由器(LBR)。对于PLR的MRT岛以外的目的地,数据包应在MRT上隧道传输到该特定颜色MRT上命名代理节点之前的非代理节点。

6.3.1. Tunneling IP Traffic Using MRT LDP Labels
6.3.1. 使用MRT LDP标签的隧道IP流量

An IP packet can be tunneled along an MRT path by pushing the appropriate MRT LDP label(s). Tunneling using LDP labels, as opposed to IP headers, has the advantage that more installed routers can do line-rate encapsulation and decapsulation using LDP than using IP. Also, no additional IP addresses would need to be allocated or signaled.

通过推送适当的MRT LDP标签,可以沿MRT路径对IP数据包进行隧道传输。与IP头相反,使用LDP标签进行隧道传输的优点是,与使用IP头相比,更多已安装的路由器可以使用LDP进行线速率封装和去封装。此外,不需要分配或通知额外的IP地址。

6.3.1.1. Tunneling IP Traffic Using MRT LDP Label Option 1A
6.3.1.1. 使用MRT LDP标签选项1A的隧道IP流量

The MRT LDP Label Option 1A forwarding mechanism uses topology-scoped FECs encoded using a single label as described in Section 6.1.1.1. When a PLR receives an IP packet that needs to be forwarded on the MRT-Red to a particular tunnel endpoint, it does a label push operation. The label pushed is the MRT-Red label for a FEC originated by the tunnel endpoint, learned from the next hop on the MRT-Red.

MRT LDP标签选项1A转发机制使用第6.1.1节所述的使用单个标签编码的拓扑范围FEC。当PLR接收到需要在MRT Red上转发到特定隧道端点的IP数据包时,它执行标签推送操作。推送的标签是由隧道端点发起的FEC的MRT红色标签,从MRT红色上的下一跳学习。

6.3.1.2. Tunneling IP Traffic Using MRT LDP Label Option 1B
6.3.1.2. 使用MRT LDP标签选项1B的隧道IP流量

The MRT LDP Label Option 1B forwarding mechanism encodes the topology and the FEC using a two-label stack as described in Section 6.1.1.2. When a PLR receives an IP packet that needs to be forwarded on the MRT-Red to a particular tunnel endpoint, the PLR pushes two labels on

MRT LDP标签选项1B转发机制使用第6.1.1.2节所述的双标签堆栈对拓扑和FEC进行编码。当PLR接收到需要在MRT Red上转发到特定隧道端点的IP数据包时,PLR推送两个标签

the IP packet. The first (inner) label is the normal LDP label learned from the next hop on the MRT-Red, associated with a FEC originated by the tunnel endpoint. The second (outer) label is the topology-id label associated with the MRT-Red.

IP数据包。第一(内部)标签是从MRT Red上的下一跳学习的正常LDP标签,与隧道端点发起的FEC相关。第二个(外部)标签是与MRT Red关联的拓扑id标签。

For completeness, we note here a potential variation that uses a single label as opposed to two labels. In order to tunnel an IP packet over an MRT to the destination of the IP packet as opposed to an arbitrary tunnel endpoint, one could just push a topology-id label directly onto the packet. An MRT transit router would need to pop the topology-id label, do an IP route lookup in the context of that topology-id label, and push the topology-id label.

为了完整性,我们在这里注意到一个潜在的变化,即使用一个标签而不是两个标签。为了通过MRT将IP数据包隧道到IP数据包的目的地,而不是任意隧道端点,可以直接将拓扑id标签推到数据包上。MRT中转路由器需要弹出拓扑id标签,在该拓扑id标签的上下文中执行IP路由查找,并推送拓扑id标签。

6.3.2. Tunneling IP Traffic Using MRT IP Tunnels
6.3.2. 使用MRT IP隧道的隧道IP流量

In order to tunnel over the MRT to a particular tunnel endpoint, the PLR encapsulates the original IP packet with an additional IP header using the MRT-Blue or MRT-Red loopback address of the tunnel endpoint.

为了通过MRT隧道到特定的隧道端点,PLR使用隧道端点的MRT蓝色或MRT红色环回地址用附加的IP报头封装原始IP分组。

6.3.3. Required Support for IP Traffic
6.3.3. IP流量所需的支持

For greatest hardware compatibility and ease in removing the MRT-topology marking at area/level boundaries, routers that support MPLS and implement IP MRT fast reroute MUST support tunneling of IP traffic using MRT LDP Label Option 1A (topology-scoped FEC encoded using a single label).

为了实现最大的硬件兼容性和在区域/级别边界移除MRT拓扑标记的方便性,支持MPLS和实现IP MRT快速重路由的路由器必须支持使用MRT LDP标签选项1A(使用单个标签编码的拓扑范围FEC)的IP流量隧道。

7. MRT Island Formation
7. 捷运岛组

The purpose of communicating support for MRT is to indicate that the MRT-Blue and MRT-Red forwarding topologies are created for transit traffic. The MRT architecture allows for different, potentially incompatible options. In order to create consistent MRT forwarding topologies, the routers participating in a particular MRT Island need to use the same set of options. These options are grouped into MRT profiles. In addition, the routers in an MRT Island all need to use the same set of nodes and links within the Island when computing the MRT forwarding topologies. This section describes the information used by a router to determine the nodes and links to include in a particular MRT Island. Some information already exists in the IGPs and can be used by MRT in Island formation, subject to the interpretation defined here.

传递对MRT的支持的目的是表明MRT蓝色和MRT红色转发拓扑是为过境交通创建的。MRT体系结构允许不同的、可能不兼容的选项。为了创建一致的MRT转发拓扑,参与特定MRT岛的路由器需要使用相同的选项集。这些选项分为MRT配置文件。此外,当计算MRT转发拓扑时,MRT岛中的路由器都需要使用岛内相同的一组节点和链路。本节描述路由器用于确定要包含在特定MRT岛中的节点和链路的信息。IGPs中已经存在一些信息,可由MRT在岛状地层中使用,但需符合此处定义的解释。

Other information needs to be communicated between routers for which there do not currently exist protocol extensions. This new information needs to be shared among all routers in an IGP area, so

其他信息需要在目前不存在协议扩展的路由器之间进行通信。这个新信息需要在IGP区域的所有路由器之间共享,所以

defining extensions to existing IGPs to carry this information makes sense. These new protocol extensions will be defined elsewhere.

定义现有IGP的扩展以承载此信息是有意义的。这些新的协议扩展将在别处定义。

Deployment scenarios using multi-topology OSPF or IS-IS, or running both IS-IS and OSPF on the same routers is out of scope for this specification. As with LFA, MRT-FRR does not support OSPF Virtual Links.

使用多拓扑OSPF或IS-IS或在同一路由器上同时运行IS-IS和OSPF的部署场景不在本规范的范围内。与LFA一样,MRT-FRR不支持OSPF虚拟链路。

At a high level, an MRT Island is defined as the set of routers supporting the same MRT profile, in the same IGP area/level and with bidirectional links interconnecting those routers. More detailed descriptions of these criteria are given below.

在较高层次上,MRT岛被定义为支持相同MRT配置文件的路由器集,位于相同的IGP区域/级别,并具有互连这些路由器的双向链路。下文对这些标准作了更详细的说明。

7.1. IGP Area or Level
7.1. IGP区域或水平

All links in an MRT Island are bidirectional and belong to the same IGP area or level. For IS-IS, a link belonging to both Level-1 and Level-2 would qualify to be in multiple MRT Islands. A given ABR or LBR can belong to multiple MRT Islands, corresponding to the areas or levels in which it participates. Inter-area forwarding behavior is discussed in Section 10.

捷运岛中的所有链路都是双向的,并且属于同一IGP区域或级别。对于IS-IS,同时属于1级和2级的链路有资格位于多个MRT岛中。给定的ABR或LBR可以属于多个MRT岛,对应于其参与的区域或级别。区域间转发行为在第10节中讨论。

7.2. Support for a Specific MRT Profile
7.2. 支持特定的MRT配置文件

All routers in an MRT Island support the same MRT profile. A router advertises support for a given MRT profile using an 8-bit MRT Profile ID value. The "MRT Profile Identifier Registry" is defined in this document. The protocol extensions for advertising the MRT Profile ID value will be defined in a future specification. A given router can support multiple MRT profiles and participate in multiple MRT Islands. The options that make up an MRT Profile, as well as the Default MRT Profile, are defined in Section 8.

MRT岛中的所有路由器都支持相同的MRT配置文件。路由器使用8位MRT配置文件ID值公布对给定MRT配置文件的支持。本文件中定义了“MRT配置文件标识符注册表”。在未来的规范中将定义用于公布MRT配置文件ID值的协议扩展。给定的路由器可以支持多个MRT配置文件并参与多个MRT孤岛。构成MRT配置文件的选项以及默认MRT配置文件在第8节中定义。

The process of MRT Island formation takes place independently for each MRT profile advertised by a given router. For example, consider a network with 40 connected routers in the same area advertising support for MRT Profile A and MRT Profile B. Two distinct MRT Islands will be formed corresponding to Profile A and Profile B, with each island containing all 40 routers. A complete set of maximally redundant trees will be computed for each island following the rules defined for each profile. If we add a third MRT Profile to this example, with Profile C being advertised by a connected subset of 30 routers, there will be a third MRT Island formed corresponding to those 30 routers, and a third set of maximally redundant trees will be computed. In this example, 40 routers would compute and install two sets of MRT transit forwarding entries corresponding to Profiles A and B, while 30 routers would compute and install three sets of MRT transit forwarding entries corresponding to Profiles A, B, and C.

MRT岛的形成过程独立于给定路由器公布的每个MRT配置文件。例如,考虑在同一区域内有40个连接路由器的网络,为MRT配置文件A和MRT配置文件提供支持。B将形成对应于配置文件A和配置文件B的两个不同的MRT岛,每个岛包含所有40个路由器。根据为每个剖面定义的规则,将为每个岛计算一组完整的最大冗余树。如果我们在此示例中添加第三个MRT配置文件,配置文件C由30个路由器的连接子集发布,则将形成对应于这30个路由器的第三个MRT岛,并且将计算第三组最大冗余树。在此示例中,40个路由器将计算并安装与配置文件A和B相对应的两组MRT中转转发条目,而30个路由器将计算并安装与配置文件A、B和C相对应的三组MRT中转转发条目。

7.3. Excluding Additional Routers and Interfaces from the MRT Island
7.3. 不包括MRT岛的额外路由器和接口

MRT takes into account existing IGP mechanisms for discouraging traffic from using particular links and routers, and it introduces an MRT-specific exclusion mechanism for links.

MRT考虑了现有的IGP机制,用于阻止使用特定链路和路由器的流量,并为链路引入了MRT特定的排除机制。

7.3.1. Existing IGP Exclusion Mechanisms
7.3.1. 现有的IGP排除机制

Mechanisms for discouraging traffic from using particular links already exist in IS-IS and OSPF. In IS-IS, an interface configured with a metric of 2^24-2 (0xFFFFFE) will only be used as a last resort. (An interface configured with a metric of 2^24-1 (0xFFFFFF) will not be advertised into the topology.) In OSPF, an interface configured with a metric of 2^16-1 (0xFFFF) will only be used as a last resort. These metrics can be configured manually to enforce administrative policy or they can be set in an automated manner as with LDP IGP synchronization [RFC5443].

IS-IS和OSPF中已经存在阻止流量使用特定链路的机制。在IS-IS中,配置了度量为2^24-2(0xFFFFFE)的接口只能用作最后手段。(配置了2^24-1(0xFFFFFF)度量的接口将不会公布到拓扑中。)在OSPF中,配置了2^16-1(0xFFFF)度量的接口将仅用作最后手段。这些指标可以手动配置以强制执行管理策略,也可以像LDP IGP同步[RFC5443]那样以自动方式设置。

Mechanisms also already exist in IS-IS and OSPF to discourage or prevent transit traffic from using a particular router. In IS-IS, the overload bit is prevents transit traffic from using a router.

IS-IS和OSPF中也已经存在阻止或阻止传输流量使用特定路由器的机制。在IS-IS中,过载位防止传输流量使用路由器。

For OSPFv2 and OSPFv3, [RFC6987] specifies setting all outgoing interface metrics to 0xFFFF to discourage transit traffic from using a router. ([RFC6987] defines the metric value 0xFFFF as MaxLinkMetric, a fixed architectural value for OSPF.) For OSPFv3, [RFC5340] specifies that a router be excluded from the intra-area SPT computation if the V6-bit or R-bit of the Link State Advertisement (LSA) options is not set in the Router LSA.

对于OSPFv2和OSPFv3,[RFC6987]指定将所有传出接口度量设置为0xFFFF,以阻止传输流量使用路由器。([RFC6987]将度量值0xFFFF定义为MaxLinkMetric,OSPF的固定体系结构值。)对于OSPFv3,[RFC5340]指定如果未在路由器LSA中设置链路状态播发(LSA)选项的V6位或R位,则将路由器排除在区域内SPT计算之外。

The following rules for MRT Island formation ensure that MRT FRR protection traffic does not use a link or router that is discouraged or prevented from carrying traffic by existing IGP mechanisms.

以下MRT岛形成规则确保MRT FRR保护通信不会使用现有IGP机制阻止或阻止承载通信的链路或路由器。

1. A bidirectional link MUST be excluded from an MRT Island if either the forward or reverse cost on the link is 0xFFFFFE (for IS-IS) or 0xFFFF for OSPF.

1. 如果双向链路的正向或反向成本为0xFFFFFE(对于is-is)或0xFFFF(对于OSPF),则必须从MRT岛中排除双向链路。

2. A router MUST be excluded from an MRT Island if it is advertised with the overload bit set (for IS-IS), or it is advertised with metric values of 0xFFFF on all of its outgoing interfaces (for OSPFv2 and OSPFv3).

2. 如果路由器以过载位集(对于is-is)播发,或在其所有输出接口(对于OSPFv2和OSPFv3)上以度量值0xFFFF播发,则必须将其从MRT孤岛中排除。

3. A router MUST be excluded from an MRT Island if it is advertised with either the V6-bit or R-bit of the LSA options not set in the Router LSA.

3. 如果路由器的LSA选项的V6位或R位未在路由器LSA中设置,则必须将其从MRT孤岛中排除。

7.3.2. MRT-Specific Exclusion Mechanism
7.3.2. MRT特定排除机制

This architecture also defines a means of excluding an otherwise usable link from MRT Islands. The protocol extensions for advertising that a link is MRT-Ineligible will be defined elsewhere. A link with either interface advertised as MRT-Ineligible MUST be excluded from an MRT Island. Note that an interface advertised as MRT-Ineligible by a router is ineligible with respect to all profiles advertised by that router.

该体系结构还定义了从MRT岛排除其他可用链路的方法。用于广告链接不符合MRT条件的协议扩展将在其他地方定义。必须从MRT岛中排除被宣传为MRT不合格的任何接口的链接。请注意,路由器公布为MRT不合格的接口对于该路由器公布的所有配置文件都不合格。

7.4. Connectivity
7.4. 连通性

All of the routers in an MRT Island MUST be connected by bidirectional links with other routers in the MRT Island. Disconnected MRT Islands will operate independently of one another.

MRT岛上的所有路由器必须通过双向链路与MRT岛上的其他路由器连接。断开连接的捷运岛将彼此独立运行。

7.5. Algorithm for MRT Island Identification
7.5. MRT岛识别算法

An algorithm that allows a computing router to identify the routers and links in the local MRT Island satisfying the above rules is given in Section 5.2 of [RFC7811].

[RFC7811]第5.2节给出了一种算法,允许计算路由器识别满足上述规则的本地MRT岛中的路由器和链路。

8. MRT Profile
8. 捷运概况

An MRT Profile is a set of values and options related to MRT behavior. The complete set of options is designated by the corresponding 8-bit Profile ID value.

MRT配置文件是一组与MRT行为相关的值和选项。整套选项由相应的8位配置文件ID值指定。

This document specifies the values and options that correspond to the Default MRT Profile (Profile ID = 0). Future documents may define other MRT Profiles by specifying the MRT Profile Options below.

本文档指定了与默认MRT配置文件(配置文件ID=0)相对应的值和选项。未来的文件可以通过指定以下MRT配置文件选项来定义其他MRT配置文件。

8.1. MRT Profile Options
8.1. 捷运概况选项

Below is a description of the values and options that define an MRT Profile.

以下是定义MRT配置文件的值和选项的说明。

MRT Algorithm: This identifies the particular algorithm for computing maximally redundant trees used by the router for this profile.

MRT算法:该算法确定了用于计算路由器用于此配置文件的最大冗余树的特定算法。

MRT-Red MT-ID: This specifies the MPLS MT-ID to be associated with the MRT-Red forwarding topology. It is allocated from the MPLS Multi-Topology Identifiers Registry.

MRT Red MT-ID:指定要与MRT Red转发拓扑关联的MPLS MT-ID。它是从MPLS多拓扑标识符注册表中分配的。

MRT-Blue MT-ID: This specifies the MPLS MT-ID to be associated with the MRT-Blue forwarding topology. It is allocated from the MPLS Multi-Topology Identifiers Registry.

MRT Blue MT-ID:指定要与MRT Blue转发拓扑关联的MPLS MT-ID。它是从MPLS多拓扑标识符注册表中分配的。

GADAG Root Selection Policy: This specifies the manner in which the GADAG root is selected. All routers in the MRT Island need to use the same GADAG root in the calculations used construct the MRTs. A valid GADAG Root Selection Policy MUST be such that each router in the MRT Island chooses the same GADAG root based on information available to all routers in the MRT Island. GADAG Root Selection Priority values, advertised as router-specific MRT parameters, MAY be used in a GADAG Root Selection Policy.

GADAG根选择策略:指定选择GADAG根的方式。MRT岛中的所有路由器都需要在构建MRT所用的计算中使用相同的GADAG根。有效的GADAG根选择策略必须确保MRT岛中的每个路由器根据MRT岛中所有路由器可用的信息选择相同的GADAG根。GADAG根选择优先级值作为特定于路由器的MRT参数公布,可在GADAG根选择策略中使用。

MRT Forwarding Mechanism: This specifies which forwarding mechanism the router uses to carry transit traffic along MRT paths. A router that supports a specific MRT forwarding mechanism must program appropriate next hops into the forwarding plane. The current options are MRT LDP Label Option 1A, MRT LDP Label Option 1B, IPv4 Tunneling, IPv6 Tunneling, and None. If IPv4 is supported, then both MRT-Red and MRT-Blue IPv4 loopback addresses SHOULD be specified. If IPv6 is supported, both MRT-Red and MRT-Blue IPv6 loopback addresses SHOULD be specified.

MRT转发机制:指定路由器用于沿MRT路径承载中转流量的转发机制。支持特定MRT转发机制的路由器必须将适当的下一跳编程到转发平面中。当前选项有MRT LDP标签选项1A、MRT LDP标签选项1B、IPv4隧道、IPv6隧道和无。如果支持IPv4,则应同时指定MRT Red和MRT Blue IPv4环回地址。如果支持IPv6,则应同时指定MRT Red和MRT Blue IPv6环回地址。

Recalculation: Recalculation specifies the process and timing by which new MRTs are computed after the topology has been modified.

重新计算:重新计算指定修改拓扑后计算新MRT的过程和时间。

Area/Level Border Behavior: This specifies how traffic traveling on the MRT-Blue or MRT-Red in one area should be treated when it passes into another area.

区域/级别边界行为:指定当一个区域的蓝色或红色捷运交通通过另一个区域时,应如何处理该区域的交通。

Other Profile-Specific Behavior: Depending upon the use-case for the profile, there may be additional profile-specific behavior.

其他特定于概要文件的行为:根据概要文件的用例,可能存在其他特定于概要文件的行为。

When a new MRT Profile is defined, new and unique values should be allocated from the "MPLS Multi-Topology Identifiers Registry", corresponding to the MRT-Red and MRT-Blue MT-ID values for the new MRT Profile.

定义新MRT配置文件时,应从“MPLS多拓扑标识符注册表”中分配新的唯一值,对应于新MRT配置文件的MRT Red和MRT Blue MT-ID值。

If a router advertises support for multiple MRT profiles, then it MUST create the transit forwarding topologies for each of those, unless the profile specifies the None option for the MRT Forwarding Mechanism.

如果路由器宣传支持多个MRT配置文件,则必须为每个配置文件创建传输转发拓扑,除非配置文件为MRT转发机制指定“无”选项。

The ability of MRT-FRR to support transit forwarding entries for multiple profiles can be used to facilitate a smooth transition from an existing deployed MRT Profile to a new MRT Profile. The new profile can be activated in parallel with the existing profile, installing the transit forwarding entries for the new profile without affecting the transit forwarding entries for the existing profile. Once the new transit forwarding state has been verified, the router can be configured to use the alternates computed by the new profile in the event of a failure.

MRT-FRR支持多个配置文件的中转转发条目的能力可用于促进从现有部署的MRT配置文件到新的MRT配置文件的平稳过渡。新配置文件可以与现有配置文件并行激活,为新配置文件安装中转转发条目,而不会影响现有配置文件的中转转发条目。一旦验证了新的传输转发状态,路由器就可以配置为在发生故障时使用新配置文件计算的备选方案。

8.2. Router-Specific MRT Parameters
8.2. 路由器特定的MRT参数

For some profiles, additional router-specific MRT parameters may need to be advertised. While the set of options indicated by the MRT Profile ID must be identical for all routers in an MRT Island, these router-specific MRT parameters may differ between routers in the same MRT Island. Several such parameters are described below.

对于某些配置文件,可能需要公布其他特定于路由器的MRT参数。虽然MRT配置文件ID指示的选项集对于MRT岛中的所有路由器必须相同,但这些特定于路由器的MRT参数在同一MRT岛中的路由器之间可能不同。下面描述了几个这样的参数。

GADAG Root Selection Priority: A GADAG Root Selection Policy MAY rely on the GADAG Root Selection Priority values advertised by each router in the MRT Island. A GADAG Root Selection Policy may use the GADAG Root Selection Priority to allow network operators to configure a parameter to ensure that the GADAG root is selected from a particular subset of routers. An example of this use of the GADAG Root Selection Priority value by the GADAG Root Selection Policy is given in the Default MRT Profile below.

GADAG根选择优先级:GADAG根选择策略可能依赖于MRT岛中每个路由器公布的GADAG根选择优先级值。GADAG根选择策略可以使用GADAG根选择优先级来允许网络运营商配置参数,以确保从路由器的特定子集中选择GADAG根。下面的默认MRT配置文件中给出了GADAG根选择策略使用GADAG根选择优先级值的示例。

MRT-Red Loopback Address: This provides the router's loopback address to reach the router via the MRT-Red forwarding topology. It can be specified for either IPv4 or IPv6. Note that this parameter is not needed to support the Default MRT Profile.

MRT Red环回地址:提供路由器的环回地址,通过MRT Red转发拓扑到达路由器。可以为IPv4或IPv6指定它。请注意,支持默认MRT配置文件不需要此参数。

MRT-Blue Loopback Address: This provides the router's loopback address to reach the router via the MRT-Blue forwarding topology. It can be specified for either IPv4 and IPv6. Note that this parameter is not needed to support the Default MRT Profile.

MRT Blue环回地址:提供路由器的环回地址,通过MRT Blue转发拓扑到达路由器。可以为IPv4和IPv6指定它。请注意,支持默认MRT配置文件不需要此参数。

Protocol extensions for advertising a router's GADAG Root Selection Priority value will be defined in other documents. Protocol extensions for the advertising a router's MRT-Red and MRT-Blue loopback addresses will be defined elsewhere.

用于公布路由器GADAG根选择优先级值的协议扩展将在其他文档中定义。用于公布路由器MRT Red和MRT Blue环回地址的协议扩展将在别处定义。

8.3. Default MRT Profile
8.3. 默认捷运模式

The following set of options defines the Default MRT Profile. The Default MRT Profile is indicated by the MRT Profile ID value of 0.

以下选项集定义了默认的MRT配置文件。默认MRT配置文件由MRT配置文件ID值0表示。

MRT Algorithm: MRT Lowpoint algorithm defined in [RFC7811].

MRT算法:[RFC7811]中定义的MRT低点算法。

MRT-Red MPLS MT-ID: This temporary registration has been allocated from the "MPLS Multi-Topology Identifiers" registry. The registration request appears in [LDP-MRT].

MRT Red MPLS MT-ID:此临时注册已从“MPLS多拓扑标识符”注册表中分配。注册请求出现在[LDP-MRT]中。

MRT-Blue MPLS MT-ID: This temporary registration has been allocated from the "MPLS Multi-Topology Identifiers" registry. The registration request appears in [LDP-MRT].

MRT Blue MPLS MT-ID:此临时注册已从“MPLS多拓扑标识符”注册表中分配。注册请求出现在[LDP-MRT]中。

GADAG Root Selection Policy: Among the routers in the MRT Island with the lowest numerical value advertised for GADAG Root Selection Priority, an implementation MUST pick the router with the highest Router ID to be the GADAG root. Note that a lower numerical value for GADAG Root Selection Priority indicates a higher preference for selection.

GADAG根选择策略:在MRT岛上为GADAG根选择优先级公布的数值最低的路由器中,实现必须选择路由器ID最高的路由器作为GADAG根。请注意,GADAG根选择优先级的数值越低,表示选择优先级越高。

Forwarding Mechanisms: MRT LDP Label Option 1A

转发机制:MRT LDP标签选项1A

Recalculation: Recalculation of MRTs SHOULD occur as described in Section 12.2. This allows the MRT forwarding topologies to support IP/LDP fast-reroute traffic.

重新计算:MRT的重新计算应按照第12.2节所述进行。这允许MRT转发拓扑支持IP/LDP快速重路由流量。

Area/Level Border Behavior: As described in Section 10, ABRs/LBRs SHOULD ensure that traffic leaving the area also exits the MRT-Red or MRT-Blue forwarding topology.

区域/级别边界行为:如第10节所述,ABR/LBR应确保离开该区域的流量也退出MRT Red或MRT Blue转发拓扑。

9. LDP Signaling Extensions and Considerations
9. LDP信令扩展及注意事项

The protocol extensions for LDP will be defined in another document. A router must indicate that it has the ability to support MRT; having this explicit allows the use of MRT-specific processing, such as special handling of FECs sent with the Rainbow MRT MT-ID.

LDP的协议扩展将在另一份文件中定义。路由器必须表明其具有支持MRT的能力;明确这一点允许使用特定于MRT的处理,例如对随Rainbow MRT MT-ID发送的FEC进行特殊处理。

A FEC sent with the Rainbow MRT MT-ID indicates that the FEC applies to all the MRT-Blue and MRT-Red MT-IDs in supported MRT profiles. The FEC-label bindings for the default shortest-path-based MT-ID 0 MUST still be sent (even though it could be inferred from the Rainbow FEC-label bindings) to ensure continuous operation of normal LDP forwarding. The Rainbow MRT MT-ID is defined to provide an easy way to handle the special signaling that is needed at ABRs or LBRs. It avoids the problem of needing to signal different MPLS labels to different LDP neighbors for the same FEC. Because the Rainbow MRT MT-ID is used only by ABRs/LBRs or an LDP egress router, it is not MRT profile specific.

与Rainbow MRT MT-ID一起发送的FEC表示FEC适用于支持的MRT配置文件中的所有MRT蓝色和MRT红色MT ID。基于默认最短路径的MT-ID 0的FEC标签绑定仍必须发送(即使可以从Rainbow FEC标签绑定推断),以确保正常LDP转发的连续操作。Rainbow MRT MT-ID被定义为提供一种简单的方式来处理ABR或LBR所需的特殊信令。它避免了需要为同一FEC向不同LDP邻居发送不同MPLS标签的问题。由于Rainbow MRT MT-ID仅由ABR/LBR或LDP出口路由器使用,因此它不是特定于MRT配置文件的。

The value of the Rainbow MRT MPLS MT-ID has been temporarily allocated from the "MPLS Multi-Topology Identifiers" registry. The registration request appears in [LDP-MRT].

Rainbow MRT MPLS MT-ID的值已从“MPLS多拓扑标识符”注册表中临时分配。注册请求出现在[LDP-MRT]中。

10. Inter-area Forwarding Behavior
10. 区域间转发行为

An ABR/LBR has two forwarding roles. First, it forwards traffic within areas. Second, it forwards traffic from one area into another. These same two roles apply for MRT transit traffic. Traffic on MRT-Red or MRT-Blue destined inside the area needs to stay on MRT-Red or MRT-Blue in that area. However, it is desirable for traffic leaving the area to also exit MRT-Red or MRT-Blue and return to shortest path forwarding.

ABR/LBR具有两个转发角色。首先,它转发区域内的流量。其次,它将流量从一个区域转发到另一个区域。这两个角色同样适用于捷运过境交通。使用红色或蓝色捷运前往该区域的交通需要停留在该区域的红色或蓝色捷运上。然而,离开该区域的交通也需要退出捷运红色或捷运蓝色,并返回最短路径转发。

For unicast MRT-FRR, the need to stay on an MRT forwarding topology terminates at the ABR/LBR whose best route is via a different area/ level. It is highly desirable to go back to the default forwarding topology when leaving an area/level. There are three basic reasons for this. First, the default topology uses shortest paths; the packet will thus take the shortest possible route to the destination. Second, this allows a single router failure that manifests itself in multiple areas (as would be the case with an ABR/LBR failure) to be separately identified and repaired around. Third, the packet can be fast-rerouted again, if necessary, due to a second distinct failure in a different area.

对于单播MRT-FRR,停留在MRT转发拓扑上的需要终止于ABR/LBR,其最佳路由是通过不同的区域/级别。离开区域/级别时,最好返回默认转发拓扑。这有三个基本原因。首先,默认拓扑使用最短路径;因此,数据包将采用最短的路径到达目的地。其次,这允许在多个区域(如ABR/LBR故障)单独识别和修复单个路由器故障。第三,如果必要,由于不同区域中的第二个明显故障,可以再次快速重新路由数据包。

In OSPF, an ABR that receives a packet on MRT-Red or MRT-Blue towards destination Z should continue to forward the packet along MRT-Red or MRT-Blue only if the best route to Z is in the same OSPF area as the interface that the packet was received on. Otherwise, the packet should be removed from MRT-Red or MRT-Blue and forwarded on the shortest-path default forwarding topology.

在OSPF中,只有当到Z的最佳路由与接收数据包的接口在同一OSPF区域时,在MRT Red或MRT Blue上接收到数据包到目的地Z的ABR才应继续沿着MRT Red或MRT Blue转发数据包。否则,数据包应从MRT Red或MRT Blue中删除,并在最短路径默认转发拓扑上转发。

The above description applies to OSPF. The same essential behavior also applies to IS-IS if one substitutes IS-IS level for OSPF area. However, the analogy with OSPF is not exact. An interface in OSPF can only be in one area, whereas an interface in IS-IS can be in both Level-1 and Level-2. Therefore, to avoid confusion and address this difference, we explicitly describe the behavior for IS-IS in Appendix A. In the following sections, only the OSPF terminology is used.

上述描述适用于OSPF。如果用IS-IS级别替代OSPF区域,同样的基本行为也适用于IS-IS。然而,与OSPF的类比并不准确。OSPF中的接口只能在一个区域中,而IS-IS中的接口可以在一级和二级中。因此,为了避免混淆并解决这一差异,我们在附录A中明确描述了IS-IS的行为。在以下章节中,仅使用OSPF术语。

10.1. ABR Forwarding Behavior with MRT LDP Label Option 1A
10.1. 使用MRT LDP标签选项1A的ABR转发行为

For LDP forwarding where a single label specifies (MT-ID, FEC), the ABR is responsible for advertising the proper label to each neighbor. Assume that an ABR has allocated three labels for a particular destination: L_primary, L_blue, and L_red. To those routers in the same area as the best route to the destination, the ABR advertises the following FEC-label bindings: L_primary for the default topology, L_blue for the MRT-Blue MT-ID, and L_red for the MRT-Red MT-ID, as expected. However, to routers in other areas, the ABR advertises the

对于单个标签指定的LDP转发(MT-ID,FEC),ABR负责向每个邻居公布适当的标签。假设ABR为特定目的地分配了三个标签:L_主标签、L_蓝色标签和L_红色标签。对于与到达目的地的最佳路由位于同一区域的那些路由器,ABR播发以下FEC标签绑定:默认拓扑为L_primary,MRT blue MT-ID为L_blue,MRT red MT-ID为L_red,如预期。然而,对于其他地区的路由器,ABR会宣传

following FEC-label bindings: L_primary for the default topology and L_primary for the Rainbow MRT MT-ID. Associating L_primary with the Rainbow MRT MT-ID causes the receiving routers to use L_primary for the MRT-Blue MT-ID and for the MRT-Red MT-ID.

以下FEC标签绑定:L_primary用于默认拓扑,L_primary用于Rainbow MRT MT-ID。将L_primary与Rainbow MRT MT-ID关联会导致接收路由器将L_primary用于MRT蓝色MT-ID和MRT红色MT-ID。

The ABR installs all next hops for the best area: primary next hops for L_primary, MRT-Blue next hops for L_blue, and MRT-Red next hops for L_red. Because the ABR advertised (Rainbow MRT MT-ID, FEC) with L_primary to neighbors not in the best area, packets from those neighbors will arrive at the ABR with a label L_primary and will be forwarded into the best area along the default topology. By controlling what labels are advertised, the ABR can thus enforce that packets exiting the area do so on the shortest-path default topology.

ABR为最佳区域安装所有下一跳:主下一跳为L_主,MRT蓝色下一跳为L_蓝色,MRT红色下一跳为L_红色。由于ABR(Rainbow MRT MT-ID,FEC)向不在最佳区域的邻居播发L_primary,因此来自这些邻居的包将到达带有L_primary标签的ABR,并将沿着默认拓扑转发到最佳区域。通过控制哪些标签被广告,ABR可以因此强制退出该区域的包在最短路径默认拓扑上这样做。

10.1.1. Motivation for Creating the Rainbow-FEC
10.1.1. 创建彩虹FEC的动机

The desired forwarding behavior could be achieved in the above example without using the Rainbow-FEC. This could be done by having the ABR advertise the following FEC-label bindings to neighbors not in the best area: L1_primary for the default topology, L1_primary for the MRT-Blue MT-ID, and L1_primary for the MRT-Red MT-ID. Doing this would require machinery to spoof the labels used in FEC-label binding advertisements on a per-neighbor basis. Such label-spoofing machinery does not currently exist in most LDP implementations and doesn't have other obvious uses.

在上述示例中,可以在不使用彩虹FEC的情况下实现所需的转发行为。这可以通过让ABR向不在最佳区域的邻居发布以下FEC标签绑定来实现:L1_primary用于默认拓扑,L1_primary用于MRT Blue MT-ID,L1_primary用于MRT Red MT-ID。这样做需要机器根据每个邻居对FEC标签绑定广告中使用的标签进行欺骗。这种标签欺骗机制目前在大多数LDP实现中并不存在,也没有其他明显的用途。

Many existing LDP implementations do however have the ability to filter FEC-label binding advertisements on a per-neighbor basis. The Rainbow-FEC allows us to reuse the existing per-neighbor FEC filtering machinery to achieve the desired result. By introducing the Rainbow FEC, we can use per-neighbor FEC-filtering machinery to advertise the FEC-label binding for the Rainbow-FEC (and filter those for MRT-Blue and MRT-Red) to non-best-area neighbors of the ABR.

然而,许多现有LDP实现确实能够基于每个邻居过滤FEC标签绑定广告。彩虹FEC允许我们重用现有的每邻居FEC过滤设备,以达到预期的效果。通过引入彩虹FEC,我们可以使用逐邻域FEC过滤机制将彩虹FEC的FEC标签绑定(并过滤MRT蓝和MRT红的FEC标签绑定)宣传到ABR的非最佳区域邻域。

An ABR may choose to either distribute the Rainbow-FEC or distribute separate MRT-Blue and MRT-Red advertisements. This is a local choice. A router that supports the MRT LDP Label Option 1A forwarding mechanism MUST be able to receive and correctly interpret the Rainbow-FEC.

ABR可以选择分发彩虹FEC或分发单独的MRT蓝色和MRT红色广告。这是当地的选择。支持MRT LDP标签选项1A转发机制的路由器必须能够接收并正确解释彩虹FEC。

10.2. ABR Forwarding Behavior with IP Tunneling (Option 2)
10.2. 具有IP隧道的ABR转发行为(选项2)

If IP tunneling is used, then the ABR behavior is dependent upon the outermost IP address. If the outermost IP address is an MRT loopback address of the ABR, then the packet is decapsulated and forwarded based upon the inner IP address, which should go on the default SPT topology. If the outermost IP address is not an MRT loopback address of the ABR, then the packet is simply forwarded along the associated

如果使用IP隧道,则ABR行为取决于最外层的IP地址。如果最外层的IP地址是ABR的MRT环回地址,则数据包将根据内部IP地址进行解封装和转发,内部IP地址应采用默认的SPT拓扑。如果最外面的IP地址不是ABR的MRT环回地址,则数据包只是沿着相关的IP地址转发

forwarding topology. A PLR sending traffic to a destination outside its local area/level will pick the MRT and use the associated MRT loopback address of the selected ABR advertising the lowest cost to the external destination.

转发拓扑。向其本地区域/级别以外的目的地发送流量的PLR将拾取MRT并使用所选ABR的相关MRT环回地址,向外部目的地宣传最低成本。

Thus, for these two MRT forwarding mechanisms (MRT LDP Label Option 1A and IP tunneling Option 2), there is no need for additional computation or per-area forwarding state.

因此,对于这两种MRT转发机制(MRT LDP标签选项1A和IP隧道选项2),不需要额外的计算或每区域转发状态。

10.3. ABR Forwarding Behavior with MRT LDP Label Option 1B
10.3. 使用MRT LDP标签选项1B的ABR转发行为

The other MRT forwarding mechanism described in Section 6 uses two labels: a topology-id label and a FEC-label. This mechanism would require that any router whose MRT-Red or MRT-Blue next hop is an ABR would need to determine whether the ABR would forward the packet out of the area/level. If so, then that router should pop off the topology-id label before forwarding the packet to the ABR.

第6节中描述的其他MRT转发机制使用两个标签:拓扑id标签和FEC标签。该机制将要求其MRT Red或MRT Blue下一跳为ABR的任何路由器将需要确定ABR是否将分组转发出区域/级别。如果是这样,那么路由器应该在将数据包转发到ABR之前弹出拓扑id标签。

For example, in Figure 3, if node H fails, node E has to put traffic towards prefix p onto MRT-Red. But since node D knows that ABR1 will use a best route from another area, it is safe for D to pop the topology-id label and just forward the packet to ABR1 along the MRT-Red next hop. ABR1 will use the shortest path in Area 10.

例如,在图3中,如果节点H失败,节点E必须将前缀p的通信量放到MRT Red上。但是,由于节点D知道ABR1将使用来自另一个区域的最佳路由,因此D可以安全地弹出拓扑id标签并沿着MRT Red下一跳将数据包转发给ABR1。ABR1将使用区域10中的最短路径。

In all cases for IS-IS and most cases for OSPF, the penultimate router can determine what decision the adjacent ABR will make. The one case where it can't be determined is when two ASBRs are in different non-backbone areas attached to the same ABR, then the ASBR's Area ID may be needed for tie-breaking (prefer the route with the largest OSPF area ID), and the Area ID isn't announced as part of the ASBR LSA. In this one case, suboptimal forwarding along the MRT in the other area would happen. If that becomes a realistic deployment scenario, protocol extensions could be developed to address this issue.

在IS-IS和OSPF的所有情况下,倒数第二个路由器可以确定相邻ABR将做出什么决定。无法确定的一种情况是,当两个ASBR位于连接到同一ABR的不同非主干区域时,可能需要ASBR的区域ID来断开连接(首选具有最大OSPF区域ID的路由),并且该区域ID不会作为ASBR LSA的一部分公布。在这一种情况下,在另一个区域沿捷运的次优转发将发生。如果这成为一个现实的部署场景,可以开发协议扩展来解决这个问题。

       +----[C]----     --[D]--[E]                --[D]--[E]
       |           \   /         \               /         \
   p--[A] Area 10 [ABR1]  Area 0 [H]--p   +-[ABR1]  Area 0 [H]-+
       |           /   \         /        |      \         /   |
       +----[B]----     --[F]--[G]        |       --[F]--[G]   |
                                          |                    |
                                          | other              |
                                          +----------[p]-------+
                                            area
        
       +----[C]----     --[D]--[E]                --[D]--[E]
       |           \   /         \               /         \
   p--[A] Area 10 [ABR1]  Area 0 [H]--p   +-[ABR1]  Area 0 [H]-+
       |           /   \         /        |      \         /   |
       +----[B]----     --[F]--[G]        |       --[F]--[G]   |
                                          |                    |
                                          | other              |
                                          +----------[p]-------+
                                            area
        

(a) Example topology (b) Proxy node view in Area 0 nodes

(a) 区域0节点中的拓扑(b)代理节点视图示例

                   +----[C]<---       [D]->[E]
                   V           \             \
                +-[A] Area 10 [ABR1]  Area 0 [H]-+
                |  ^           /             /   |
                |  +----[B]<---       [F]->[G]   V
                |                                |
                +------------->[p]<--------------+
        
                   +----[C]<---       [D]->[E]
                   V           \             \
                +-[A] Area 10 [ABR1]  Area 0 [H]-+
                |  ^           /             /   |
                |  +----[B]<---       [F]->[G]   V
                |                                |
                +------------->[p]<--------------+
        

(c) rSPT towards destination p

(c) 到达目的地p的rSPT

             ->[D]->[E]                         -<[D]<-[E]
            /          \                       /         \
       [ABR1]  Area 0 [H]-+             +-[ABR1]         [H]
                      /   |             |      \
               [F]->[G]   V             V       -<[F]<-[G]
                          |             |
                          |             |
                [p]<------+             +--------->[p]
        
             ->[D]->[E]                         -<[D]<-[E]
            /          \                       /         \
       [ABR1]  Area 0 [H]-+             +-[ABR1]         [H]
                      /   |             |      \
               [F]->[G]   V             V       -<[F]<-[G]
                          |             |
                          |             |
                [p]<------+             +--------->[p]
        

(d) MRT-Blue in Area 0 (e) MRT-Red in Area 0

(d) 区域0(e)中的MRT蓝色区域0中的MRT红色区域

Figure 3: ABR Forwarding Behavior and MRTs

图3:ABR转发行为和MRT

11. Prefixes Multiply Attached to the MRT Island
11. 附加在捷运岛上的前缀成倍增加

How a computing router S determines its local MRT Island for each supported MRT profile is already discussed in Section 7.

第7节已经讨论了计算路由器如何为每个受支持的MRT配置文件确定其本地MRT岛。

There are two types of prefixes or FECs that may be multiply attached to an MRT Island. The first type are multihomed prefixes that usually connect at a domain or protocol boundary. The second type represent routers that do not support the profile for the MRT Island.

有两种类型的前缀或FEC可以多重连接到MRT岛。第一种类型是多址前缀,通常在域或协议边界连接。第二种类型表示不支持MRT岛配置文件的路由器。

The key difference is whether the traffic, once out of the MRT Island, might re-enter the MRT Island if a loop-free exit point is not selected.

关键的区别在于,如果未选择无环路出口点,车辆一旦离开地铁岛,是否可能重新进入地铁岛。

FRR using LFA has the useful property that it is able to protect multihomed prefixes against ABR failure. For instance, if a prefix from the backbone is available via both ABR A and ABR B, if A fails, then the traffic should be redirected to B. This can be accomplished with MRT FRR as well.

使用LFA的FRR具有一个有用的特性,即它能够保护多址前缀免受ABR故障的影响。例如,如果来自主干网的前缀通过ABR a和ABR B都可用,如果a失败,则应将流量重定向到B。这也可以通过MRT FRR实现。

If ASBR protection is desired, this has additional complexities if the ASBRs are in different areas. Similarly, protecting labeled BGP traffic in the event of an ASBR failure has additional complexities due to the per-ASBR label spaces involved.

如果需要ASBR保护,则如果ASBR位于不同的区域,这会增加复杂性。类似地,由于涉及到每个ASBR标签空间,因此在ASBR故障时保护标记的BGP通信量具有额外的复杂性。

As discussed in [RFC5286], a multihomed prefix could be:

如[RFC5286]中所述,多址前缀可以是:

o An out-of-area prefix announced by more than one ABR,

o 由多个ABR宣布的区域外前缀,

o An AS-External route announced by two or more ASBRs,

o 两个或多个ASBR宣布的AS外部路线,

o A prefix with iBGP multipath to different ASBRs,

o 带有iBGP多路径到不同ASBR的前缀,

o etc.

o 等

See Appendix B for a discussion of a general issue with multihomed prefixes connected in two different areas.

关于多址前缀在两个不同区域连接的一般问题的讨论,请参见附录B。

There are also two different approaches to protection. The first is tunnel endpoint selection where the PLR picks a router to tunnel to where that router is loop-free with respect to the failure-point. Conceptually, the set of candidate routers to provide LFAs expands to all routers that can be reached via an MRT alternate, attached to the prefix.

还有两种不同的保护方法。第一种是隧道端点选择,其中PLR选择一个路由器到隧道,该路由器相对于故障点是无环路的。从概念上讲,提供LFA的候选路由器集扩展到所有可通过附加到前缀的MRT备选路由器到达的路由器。

The second is to use a proxy-node, which can be named via MPLS label or IP address, and pick the appropriate label or IP address to reach it on either MRT-Blue or MRT-Red as appropriate to avoid the failure point. A proxy-node can represent a destination prefix that can be attached to the MRT Island via at least two routers. It is termed a named proxy-node if there is a way that traffic can be encapsulated to reach specifically that proxy-node; this could be because there is an LDP FEC for the associated prefix or because MRT-Red and MRT-Blue IP addresses are advertised (in an as-yet undefined fashion) for that proxy-node. Traffic to a named proxy-node may take a different path than traffic to the attaching router; traffic is also explicitly forwarded from the attaching router along a predetermined interface towards the relevant prefixes.

第二种方法是使用代理节点,该节点可以通过MPLS标签或IP地址命名,并根据需要选择适当的标签或IP地址,通过MRT蓝色或MRT红色到达该节点,以避免出现故障点。代理节点可以表示可以通过至少两个路由器连接到MRT岛的目的地前缀。如果有一种方式可以将通信量封装到特定的代理节点,则称之为命名代理节点;这可能是因为相关前缀有一个LDP FEC,或者是因为该代理节点的MRT Red和MRT Blue IP地址被公布(以尚未定义的方式)。到命名代理节点的流量可以采用与到连接路由器的流量不同的路径;通信量也从连接路由器沿着预定接口显式地转发到相关前缀。

For IP traffic, multihomed prefixes can use tunnel endpoint selection. For IP traffic that is destined to a router outside the MRT Island, if that router is the egress for a FEC advertised into the MRT Island, then the named proxy-node approach can be used.

对于IP流量,多址前缀可以使用隧道端点选择。对于目的地为MRT岛外路由器的IP流量,如果该路由器是播发到MRT岛的FEC的出口,则可以使用命名代理节点方法。

For LDP traffic, there is always a FEC advertised into the MRT Island. The named proxy-node approach should be used, unless the computing router S knows the label for the FEC at the selected tunnel endpoint.

对于LDP流量,在捷运岛上总是有一个FEC广告。除非计算路由器S知道所选隧道端点处FEC的标签,否则应使用命名代理节点方法。

If a FEC is advertised from outside the MRT Island into the MRT Island and the forwarding mechanism specified in the profile includes LDP Label Option 1A, then the routers learning that FEC MUST also advertise labels for (MRT-Red, FEC) and (MRT-Blue, FEC) to neighbors inside the MRT Island. Any router receiving a FEC corresponding to a router outside the MRT Island or to a multihomed prefix MUST compute and install the transit MRT-Blue and MRT-Red next hops for that FEC. The FEC-label bindings for the topology-scoped FECs ((MT-ID 0, FEC), (MRT-Red, FEC), and (MRT-Blue, FEC)) MUST also be provided via LDP to neighbors inside the MRT Island.

如果从MRT岛外部向MRT岛播发FEC,并且配置文件中指定的转发机制包括LDP标签选项1A,则学习到FEC还必须向MRT岛内部的邻居播发(MRT红色,FEC)和(MRT蓝色,FEC)标签的路由器。任何接收到与MRT岛外路由器或多址前缀对应的FEC的路由器必须计算并安装该FEC的transit MRT Blue和MRT Red下一跳。拓扑范围的FEC((MT-ID 0,FEC),(MRT红色,FEC)和(MRT蓝色,FEC))的FEC标签绑定也必须通过LDP提供给MRT岛内的邻居。

11.1. Protecting Multihomed Prefixes Using Tunnel Endpoint Selection
11.1. 使用隧道端点选择保护多宿主前缀

Tunnel endpoint selection is a local matter for a router in the MRT Island since it pertains to selecting and using an alternate and does not affect the transit MRT-Red and MRT-Blue forwarding topologies.

隧道端点选择对于MRT岛上的路由器来说是一个局部问题,因为它涉及到选择和使用备用,并且不影响transit MRT Red和MRT Blue转发拓扑。

Let the computing router be S and the next hop F be the node whose failure is to be avoided. Let the destination be prefix p. Have A be the router to which the prefix p is attached for S's shortest path to p.

假设计算路由器是S,下一跳F是要避免失败的节点。让目的地为前缀p。将A作为前缀p附加到的路由器,以获得S到p的最短路径。

The candidates for tunnel endpoint selection are those to which the destination prefix is attached in the area/level. For a particular candidate B, it is necessary to determine if B is loop-free to reach p with respect to S and F for node-protection or at least with respect to S and the link (S, F) for link-protection. If B will always prefer to send traffic to p via a different area/level, then this is definitional. Otherwise, distance-based computations are necessary and an SPF from B's perspective may be necessary. The following equations give the checks needed; the rationale is similar to that given in [RFC5286]. In the inequalities below, D_opt(X,Y) means the shortest distance from node X to node Y, and D_opt(X,p) means the shortest distance from node X to prefix p.

隧道端点选择的候选对象是那些在区域/标高中附加了目标前缀的对象。对于特定候选者B,有必要确定B对于节点保护的S和F,或者至少对于链路保护的S和链路(S,F),是无环到达p的。如果B总是希望通过不同的区域/级别向p发送流量,则这是定义。否则,基于距离的计算是必要的,从B的角度来看,SPF可能是必要的。以下方程式给出了所需的检查;其原理与[RFC5286]中给出的原理相似。在下面的不等式中,D_opt(X,Y)表示从节点X到节点Y的最短距离,D_opt(X,p)表示从节点X到前缀p的最短距离。

   Loop-Free for S: D_opt(B, p) < D_opt(B, S) + D_opt(S, p)
        
   Loop-Free for S: D_opt(B, p) < D_opt(B, S) + D_opt(S, p)
        
   Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(F, p)
        
   Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(F, p)
        

The latter is equivalent to the following, which avoids the need to compute the shortest path from F to p.

后者相当于以下内容,从而避免了计算从F到p的最短路径的需要。

  Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(S, p) - D_opt(S, F)
        
  Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(S, p) - D_opt(S, F)
        

Finally, the rules for Endpoint selection are given below. The basic idea is to repair to the prefix-advertising router selected for the shortest-path and only to select and tunnel to a different endpoint if necessary (e.g., A=F or F is a cut-vertex or the link (S,F) is a cut-link).

最后,下面给出了端点选择的规则。基本思想是修复为最短路径选择的前缀广告路由器,并仅在必要时选择和隧道到不同的端点(例如,a=F或F是切割顶点或链接(S,F)是切割链接)。

1. Does S have a node-protecting alternate to A? If so, select that. Tunnel the packet to A along that alternate. For example, if LDP is the forwarding mechanism, then push the label (MRT-Red, A) or (MRT-Blue, A) onto the packet.

1. S是否有一个节点保护备用节点?如果是,请选择该选项。将数据包沿该备用通道隧道到A。例如,如果LDP是转发机制,则将标签(MRT红色,A)或(MRT蓝色,A)推到数据包上。

2. If not, then is there a router B that is loop-free to reach p while avoiding both F and S? If so, select B as the endpoint. Determine the MRT alternate to reach B while avoiding F. Tunnel the packet to B along that alternate. For example, with LDP, push the label (MRT-Red, B) or (MRT-Blue, B) onto the packet.

2. 如果没有,那么是否有一个路由器B在避免F和S的同时无环路到达p?如果是,请选择B作为端点。确定到达B的捷运备降线,同时避开F。沿着该备降线将数据包传送到B。例如,使用LDP,将标签(MRT红色,B)或(MRT蓝色,B)推到数据包上。

3. If not, then does S have a link-protecting alternate to A? If so, select that.

3. 如果没有,那么S是否有到a的备用链路保护?如果是,请选择该选项。

4. If not, then is there a router B that is loop-free to reach p while avoiding S and the link from S to F? If so, select B as the endpoint and the MRT alternate for reaching B from S that avoid the link (S,F).

4. 如果没有,那么是否有一个路由器B在避开S和从S到F的链路的同时无环路到达p?如果是这样,选择B作为终点,并选择MRT备选方案从S到达B,以避免连接(S,F)。

The tunnel endpoint selected will receive a packet destined to itself and, being the egress, will pop that MPLS label (or have signaled Implicit Null) and forward based on what is underneath. This suffices for IP traffic since the tunnel endpoint can use the IP header of the original packet to continue forwarding the packet. However, tunneling of LDP traffic requires targeted LDP sessions for learning the FEC-label binding at the tunnel endpoint.

选择的隧道端点将接收一个目的地为自身的数据包,作为出口,将弹出该MPLS标签(或已发出隐式Null信号)并根据下面的内容转发。这对于IP通信就足够了,因为隧道端点可以使用原始数据包的IP报头继续转发数据包。然而,LDP流量的隧道需要目标LDP会话来学习隧道端点处的FEC标签绑定。

11.2. Protecting Multihomed Prefixes Using Named Proxy-Nodes
11.2. 使用命名代理节点保护多宿主前缀

Instead, the named proxy-node method works with LDP traffic without the need for targeted LDP sessions. It also has a clear advantage over tunnel endpoint selection, in that it is possible to explicitly forward from the MRT Island along an interface to a loop-free island neighbor when that interface may not be a primary next hop.

取而代之的是,命名代理节点方法可以处理LDP流量,而不需要目标LDP会话。与隧道端点选择相比,它还有一个明显的优势,即当接口可能不是主下一跳时,可以沿着接口显式地从MRT岛转发到无环岛邻居。

A named proxy-node represents one or more destinations and, for LDP forwarding, has a FEC associated with it that is signaled into the MRT Island. Therefore, it is possible to explicitly label packets to go to (MRT-Red, FEC) or (MRT-Blue, FEC); at the border of the MRT Island, the label will swap to meaning (MT-ID 0, FEC). It would be possible to have named proxy-nodes for IP forwarding, but this would require extensions to signal two IP addresses to be associated with MRT-Red and MRT-Blue for the proxy-node. A named proxy-node can be uniquely represented by the two routers in the MRT Island to which it is connected. The extensions to signal such IP addresses will be defined elsewhere. The details of what label-bindings must be originated will be described in another document.

命名代理节点表示一个或多个目的地,并且对于LDP转发,具有与其相关联的FEC,该FEC通过信号发送到MRT岛。因此,可以显式地标记要转到(MRT Red,FEC)或(MRT Blue,FEC)的包;在捷运岛的边界处,标签将替换为含义(MT-ID 0,FEC)。可以为IP转发指定代理节点,但这需要扩展来通知两个IP地址,以便与代理节点的MRT Red和MRT Blue关联。一个命名的代理节点可以由它所连接的MRT岛中的两个路由器唯一地表示。发送此类IP地址信号的扩展将在别处定义。必须创建哪些标签绑定的详细信息将在另一个文档中描述。

Computing the MRT next hops to a named proxy-node and the MRT alternate for the computing router S to avoid a particular failure node F is straightforward. The details of the simple constant-time functions, Select_Proxy_Node_NHs() and Select_Alternates_Proxy_Node(), are given in [RFC7811]. A key point is that computing these MRT next hops and alternates can be done as new named proxy-nodes are added or removed without requiring a new MRT computation or impacting other existing MRT paths. This maps very well to, for example, how OSPFv2 (see [RFC2328], Section 16.5) does incremental updates for new summary-LSAs.

计算下一跳到命名代理节点的MRT和计算路由器S的MRT备选方案以避免特定故障节点F是简单的。[RFC7811]中给出了简单的恒定时间函数Select_Proxy_Node_NHs()和Select_Alternates_Proxy_Node()的详细信息。一个关键点是,在添加或删除新的命名代理节点时,可以计算这些MRT下一跳和候补,而不需要新的MRT计算或影响其他现有MRT路径。例如,这与OSPFv2(参见[RFC2328],第16.5节)如何为新的汇总LSA进行增量更新非常吻合。

The remaining question is how to attach the named proxy-node to the MRT Island; all the routers in the MRT Island MUST do this consistently. No more than two routers in the MRT Island can be selected; one should only be selected if there are no others that meet the necessary criteria. The named proxy-node is logically part of the area/level.

剩下的问题是如何将命名的代理节点附加到MRT岛;捷运岛上的所有路由器都必须始终如一地这样做。MRT岛内最多可选择两台路由器;只有在没有其他符合必要标准的情况下,才应选择一个。命名的代理节点在逻辑上是区域/级别的一部分。

There are two sources for candidate routers in the MRT Island to connect to the named proxy-node. The first set is made up of those routers in the MRT Island that are advertising the prefix; the named-proxy-cost assigned to each prefix-advertising router is the announced cost to the prefix. The second set is made up of those routers in the MRT Island that are connected to routers not in the MRT Island but in the same area/level; such routers will be defined as Island Border Routers (IBRs). The routers connected to the IBRs that are not in the MRT Island and are in the same area/level as the MRT Island are Island Neighbors (INs).

MRT岛中的候选路由器有两个连接到指定代理节点的源。第一组是由那些在捷运岛上宣传前缀的路由器组成;分配给每个前缀广告路由器的命名代理成本是前缀的公布成本。第二组由MRT岛上的路由器组成,这些路由器与不在MRT岛上但在同一区域/级别的路由器相连;此类路由器将被定义为岛屿边界路由器(IBR)。连接到IBR的路由器不在MRT岛上,并且与MRT岛位于同一区域/级别,它们是岛邻居(INs)。

Since packets sent to the named proxy-node along MRT-Red or MRT-Blue may come from any router inside the MRT Island, it is necessary that whatever router to which an IBR forwards the packet be loop-free with respect to the whole MRT Island for the destination. Thus, an IBR is a candidate router only if it possesses at least one IN whose shortest path to the prefix does not enter the MRT Island. A method

由于沿着MRT Red或MRT Blue发送到指定代理节点的数据包可能来自MRT岛内的任何路由器,因此IBR将数据包转发到的任何路由器都必须相对于目的地的整个MRT岛是无环路的。因此,只有当IBR至少拥有一个到前缀的最短路径未进入MRT岛时,IBR才是候选路由器。方法

for identifying Loop-Free Island Neighbors (LFINs) is given in [RFC7811]. The named-proxy-cost assigned to each (IBR, IN) pair is cost(IBR, IN) + D_opt(IN, prefix).

[RFC7811]中给出了识别无环岛邻居(LFIN)的方法。分配给每对(IBR,IN)的命名代理成本是成本(IBR,IN)+D_opt(IN,前缀)。

From the set of prefix-advertising routers and the set of IBRs with at least one LFIN, the two routers with the lowest named-proxy-cost are selected. Ties are broken based upon the lowest Router ID. For ease of discussion, the two selected routers will be referred to as proxy-node attachment routers.

从前缀广告路由器集合和具有至少一个LFIN的ibr集合中,选择具有最低命名代理成本的两个路由器。根据最低的路由器ID断开连接。为便于讨论,所选的两个路由器将被称为代理节点连接路由器。

A proxy-node attachment router has a special forwarding role. When a packet is received destined to (MRT-Red, prefix) or (MRT-Blue, prefix), if the proxy-node attachment router is an IBR, it MUST swap to the shortest path forwarding topology (e.g., swap to the label for (MT-ID 0, prefix) or remove the outer IP encapsulation) and forward the packet to the IN whose cost was used in the selection. If the proxy-node attachment router is not an IBR, then the packet MUST be removed from the MRT forwarding topology and sent along the interface(s) that caused the router to advertise the prefix; this interface might be out of the area/level/AS.

代理节点连接路由器具有特殊的转发角色。当接收到目的地为(MRT红色,前缀)或(MRT蓝色,前缀)的数据包时,如果代理节点连接路由器是IBR,则它必须交换到最短路径转发拓扑(例如,交换到(MT-ID 0,前缀)的标签或移除外部IP封装),并将数据包转发到选择中使用成本的IN。如果代理节点连接路由器不是IBR,则必须将数据包从MRT转发拓扑中移除,并沿着导致路由器公布前缀的接口发送;此接口可能在区域/级别/AS之外。

11.3. MRT Alternates for Destinations outside the MRT Island
11.3. 捷运轮换前往捷运岛以外的目的地

A natural concern with new functionality is how to have it be useful when it is not deployed across an entire IGP area. In the case of MRT FRR, where it provides alternates when appropriate LFAs aren't available, there are also deployment scenarios where it may make sense to only enable some routers in an area with MRT FRR. A simple example of such a scenario would be a ring of six or more routers that is connected via two routers to the rest of the area.

新功能的一个自然关注点是,当它没有部署到整个IGP区域时,如何使它变得有用。在MRT FRR的情况下,当适当的LFA不可用时,它会提供替代方案,在部署场景中,仅在具有MRT FRR的区域中启用某些路由器可能是有意义的。这种情况的一个简单示例是由六个或更多路由器组成的环,通过两个路由器连接到该区域的其余部分。

Destinations inside the local island can obviously use MRT alternates. Destinations outside the local island can be treated like a multihomed prefix and either endpoint selection or Named Proxy-Nodes can be used. Named proxy-nodes MUST be supported when LDP forwarding is supported and a label-binding for the destination is sent to an IBR.

当地岛屿内的目的地显然可以使用捷运轮班。本地岛之外的目的地可以被视为多宿前缀,可以使用端点选择或命名代理节点。当支持LDP转发并且将目标的标签绑定发送到IBR时,必须支持命名代理节点。

Naturally, there are more-complicated options to improve coverage, such as connecting multiple MRT Islands across tunnels, but the need for the additional complexity has not been justified.

当然,有更复杂的方案来提高覆盖率,例如跨隧道连接多个地铁岛,但没有理由需要额外的复杂性。

12. Network Convergence and Preparing for the Next Failure
12. 网络融合,为下一次失败做好准备

After a failure, MRT detours ensure that packets reach their intended destination while the IGP has not reconverged onto the new topology. As link-state updates reach the routers, the IGP process calculates the new shortest paths. Two things need attention: micro-loop prevention and MRT recalculation.

故障后,MRT绕道确保数据包到达其预期目的地,同时IGP没有重新聚合到新拓扑上。当链路状态更新到达路由器时,IGP过程计算新的最短路径。有两件事需要注意:微环预防和MRT重新计算。

12.1. Micro-loop Prevention and MRTs
12.1. 微环预防与MRTs

A micro-loop is a transient packet-forwarding loop among two or more routers that can occur during convergence of IGP forwarding state. [RFC5715] discusses several techniques for preventing micro-loops. This section discusses how MRT-FRR relates to two of the micro-loop prevention techniques discussed in [RFC5715]: Nearside and Farside Tunneling.

微循环是两个或多个路由器之间的瞬态包转发循环,可在IGP转发状态收敛期间发生。[RFC5715]讨论了几种防止微回路的技术。本节讨论MRT-FRR如何与[RFC5715]中讨论的两种微回路预防技术相关:近侧和远侧隧道。

In Nearside Tunneling, a router (PLR) adjacent to a failure performs local repair and informs remote routers of the failure. The remote routers initially tunnel affected traffic to the nearest PLR, using tunnels that are unaffected by the failure. Once the forwarding state for normal shortest path routing has converged, the remote routers return the traffic to shortest path forwarding. MRT-FRR is relevant for Nearside Tunneling for the following reason. The process of tunneling traffic to the PLRs and waiting a sufficient amount of time for IGP forwarding state convergence with Nearside Tunneling means that traffic will generally rely on the local repair at the PLR for longer than it would in the absence of Nearside Tunneling. Since MRT-FRR provides 100% coverage for single link and node failure, it may be an attractive option to provide the local repair paths when Nearside Tunneling is deployed.

在近侧隧道中,故障附近的路由器(PLR)执行本地修复,并将故障通知远程路由器。远程路由器最初使用不受故障影响的隧道将受影响的流量隧道到最近的PLR。一旦正常最短路径路由的转发状态聚合,远程路由器将流量返回到最短路径转发。MRT-FRR与近侧隧道相关,原因如下。通过隧道将流量传输到PLR并等待足够长的时间,以便IGP转发状态与近侧隧道进行会聚,这意味着流量通常比在没有近侧隧道的情况下更依赖于PLR的局部修复。由于MRT-FRR为单链路和节点故障提供100%的覆盖率,因此在部署近侧隧道时,提供本地修复路径可能是一个有吸引力的选择。

MRT-FRR is also relevant for the Farside Tunneling micro-loop prevention technique. In Farside Tunneling, remote routers tunnel traffic affected by a failure to a node downstream of the failure with respect to traffic destination. This node can be viewed as being on the farside of the failure with respect to the node initiating the tunnel. Note that the discussion of Farside Tunneling in [RFC5715] focuses on the case where the farside node is immediately adjacent to a failed link or node. However, the farside node may be any node downstream of the failure with respect to traffic destination, including the destination itself. The tunneling mechanism used to reach the farside node must be unaffected by the failure. The alternative forwarding paths created by MRT-FRR have the potential to be used to forward traffic from the remote routers upstream of the failure all the way to the destination. In the event of failure, either the MRT-Red or MRT-Blue path from the remote upstream router to the destination is guaranteed to avoid a link

MRT-FRR还与远侧隧道微回路预防技术相关。在远端隧道中,远程路由器将受故障影响的通信量隧道到故障下游的节点,该节点相对于通信目的地。相对于启动隧道的节点,该节点可以被视为处于故障的远端。注意,[RFC5715]中对远端隧道的讨论集中在远端节点紧邻故障链路或节点的情况。然而,远端节点可以是关于业务目的地的故障下游的任何节点,包括目的地本身。用于到达远端节点的隧道机制必须不受故障的影响。MRT-FRR创建的替代转发路径有可能用于将故障上游远程路由器的流量转发到目的地。在发生故障的情况下,保证从远程上游路由器到目的地的MRT Red或MRT Blue路径能够避免链路

failure or inferred node failure. The MRT forwarding paths are also guaranteed to not be subject to micro-loops because they are locked to the topology before the failure.

失败或推断的节点失败。MRT转发路径也保证不受微循环的影响,因为它们在发生故障之前被锁定在拓扑上。

We note that the computations in [RFC7811] address the case of a PLR adjacent to a failure determining which choice of MRT-Red or MRT-Blue will avoid a failed link or node. More computation may be required for an arbitrary remote upstream router to determine whether to choose MRT-Red or MRT-Blue for a given destination and failure.

我们注意到,[RFC7811]中的计算处理了故障附近的PLR的情况,确定选择MRT Red或MRT Blue将避免故障链路或节点。对于任意远程上行路由器,可能需要进行更多的计算,以确定是否为给定的目的地和故障选择MRT Red或MRT Blue。

12.2. MRT Recalculation for the Default MRT Profile
12.2. 默认MRT配置文件的MRT重新计算

This section describes how the MRT recalculation SHOULD be performed for the Default MRT Profile. This is intended to support FRR applications. Other approaches are possible, but they are not specified in this document.

本节介绍如何对默认MRT配置文件执行MRT重新计算。这旨在支持FRR应用程序。也可以采用其他方法,但本文件未规定。

When a failure event happens, traffic is put by the PLRs onto the MRT topologies. After that, each router recomputes its SPT and moves traffic over to that. Only after all the PLRs have switched to using their SPTs and traffic has drained from the MRT topologies should each router install the recomputed MRTs into the FIBs.

当发生故障事件时,PLR将交通量置于MRT拓扑上。之后,每个路由器重新计算其SPT,并将流量转移到该SPT。只有在所有PLR切换到使用其SPT并且流量从MRT拓扑中排出后,每个路由器才应将重新计算的MRT安装到FIB中。

At each router, therefore, the sequence is as follows:

因此,在每个路由器上,顺序如下:

1. Receive failure notification

1. 接收失败通知

2. Recompute SPT.

2. 重新计算SPT。

3. Install the new SPT in the FIB.

3. 在FIB中安装新的SPT。

4. If the network was stable before the failure occurred, wait a configured (or advertised) period for all routers to be using their SPTs and traffic to drain from the MRTs.

4. 如果网络在故障发生之前是稳定的,请等待一段配置(或公布)时间,以便所有路由器使用其SPT,并从MRT中排出流量。

5. Recompute MRTs.

5. 重新计算捷运系统。

6. Install new MRTs in the FIB.

6. 在FIB中安装新的MRT。

While the recomputed MRTs are not installed in the FIB, protection coverage is lowered. Therefore, it is important to recalculate the MRTs and install them quickly.

虽然重新计算的MRT未安装在FIB中,但保护覆盖率降低。因此,重要的是重新计算MRT并快速安装。

New protocol extensions for advertising the time needed to recompute shortest path routes and install them in the FIB will be defined elsewhere.

其他地方将定义新的协议扩展,用于公布重新计算最短路径路由并将其安装到FIB中所需的时间。

13. Operational Considerations
13. 业务考虑

The following aspects of MRT-FRR are useful to consider when deploying the technology in different operational environments and network topologies.

当在不同的操作环境和网络拓扑中部署技术时,MRT-FRR的以下方面是有用的。

13.1. Verifying Forwarding on MRT Paths
13.1. 验证MRT路径上的转发

The forwarding paths created by MRT-FRR are not used by normal (non-FRR) traffic. They are only used to carry FRR traffic for a short period of time after a failure has been detected. It is RECOMMENDED that an operator proactively monitor the MRT forwarding paths in order to be certain that the paths will be able to carry FRR traffic when needed. Therefore, an implementation SHOULD provide an operator with the ability to test MRT paths with Operations, Administration, and Maintenance (OAM) traffic. For example, when MRT paths are realized using LDP labels distributed for topology-scoped FECs, an implementation can use the MPLS ping and traceroute as defined in [RFC4379] and extended in [RFC7307] for topology-scoped FECs.

由MRT-FRR创建的转发路径不被正常(非FRR)流量使用。它们仅用于在检测到故障后的短时间内承载FRR流量。建议运营商主动监控MRT转发路径,以确保路径在需要时能够承载FRR流量。因此,一个实现应该为运营商提供使用运营、管理和维护(OAM)流量测试MRT路径的能力。例如,当使用为拓扑范围的fec分发的LDP标签实现MRT路径时,实现可以使用在[RFC4379]中定义并在[RFC7307]中扩展的用于拓扑范围的fec的MPLS ping和traceroute。

13.2. Traffic Capacity on Backup Paths
13.2. 备份路径上的流量容量

During a fast-reroute event initiated by a PLR in response to a network failure, the flow of traffic in the network will generally not be identical to the flow of traffic after the IGP forwarding state has converged, taking the failure into account. Therefore, even if a network has been engineered to have enough capacity on the appropriate links to carry all traffic after the IGP has converged after the failure, the network may still not have enough capacity on the appropriate links to carry the flow of traffic during a fast-reroute event. This can result in more traffic loss during the fast-reroute event than might otherwise be expected.

在PLR响应网络故障而发起的快速重路由事件期间,考虑到故障,网络中的业务流通常与IGP转发状态会聚后的业务流不同。因此,即使网络已被设计为在IGP在故障后聚合之后在适当链路上具有足够的容量来承载所有业务,网络也可能在适当链路上仍然没有足够的容量来承载快速重路由事件期间的业务流。这可能会在快速重路由事件期间导致比预期更多的流量损失。

Note that there are two somewhat distinct aspects to this phenomenon. The first is that the path from the PLR to the destination during the fast-reroute event may be different from the path after the IGP converges. In this case, any traffic for the destination that reaches the PLR during the fast-reroute event will follow a different path from the PLR to the destination than will be followed after IGP convergence.

请注意,这种现象有两个不同的方面。第一个是在快速重路由事件期间从PLR到目的地的路径可能不同于IGP收敛后的路径。在这种情况下,在快速重路由事件期间到达PLR的目的地的任何通信量将遵循从PLR到目的地的不同路径,而不是IGP收敛后的路径。

The second aspect is that the amount of traffic arriving at the PLR for affected destinations during the fast-reroute event may be larger than the amount of traffic arriving at the PLR for affected destinations after IGP convergence. Immediately after a failure, any non-PLR routers that were sending traffic to the PLR before the failure will continue sending traffic to the PLR, and that traffic will be carried over backup paths from the PLR to the destinations.

第二方面是,在快速重路由事件期间到达受影响目的地的PLR的业务量可能大于在IGP收敛之后到达受影响目的地的PLR的业务量。故障发生后,在故障发生之前向PLR发送流量的任何非PLR路由器将立即继续向PLR发送流量,并且该流量将通过备份路径从PLR传输到目的地。

After IGP convergence, upstream non-PLR routers may direct some traffic away from the PLR.

IGP收敛后,上游非PLR路由器可能会将一些流量从PLR引导出去。

In order to reduce or eliminate the potential for transient traffic loss due to inadequate capacity during fast-reroute events, an operator can model the amount of traffic taking different paths during a fast-reroute event. If it is determined that there is not enough capacity to support a given fast-reroute event, the operator can address the issue either by augmenting capacity on certain links or modifying the backup paths themselves.

为了减少或消除快速重路由事件期间由于容量不足而导致的瞬时流量损失的可能性,操作员可以对快速重路由事件期间采用不同路径的流量进行建模。如果确定没有足够的容量支持给定的快速重路由事件,操作员可以通过增加某些链路上的容量或修改备份路径本身来解决该问题。

The MRT Lowpoint algorithm produces a pair of diverse paths to each destination. These paths are generated by following the directed links on a common GADAG. The decision process for constructing the GADAG in the MRT Lowpoint algorithm takes into account individual IGP link metrics. At any given node, links are explored in order from lowest IGP metric to highest IGP metric. Additionally, the process for constructing the MRT-Red and Blue trees uses SPF traversals of the GADAG. Therefore, the IGP link metric values affect the computed backup paths. However, adjusting the IGP link metrics is not a generally applicable tool for modifying the MRT backup paths. Achieving a desired set of MRT backup paths by adjusting IGP metrics while at the same time maintaining the desired flow of traffic along the shortest paths is not possible in general.

MRT低点算法生成到每个目的地的一对不同路径。这些路径是通过遵循公共GADAG上的定向链接生成的。在MRT低点算法中构建GADAG的决策过程考虑了各个IGP链路度量。在任何给定节点上,按从最低IGP度量到最高IGP度量的顺序探索链路。此外,构建MRT红色和蓝色树的过程使用GADAG的SPF遍历。因此,IGP链路度量值会影响计算的备份路径。但是,调整IGP链路指标并不是修改MRT备份路径的普遍适用工具。通过调整IGP指标来实现所需的MRT备份路径集,同时沿最短路径维持所需的交通流,这通常是不可能的。

MRT-FRR allows an operator to exclude a link from the MRT Island, and thus the GADAG, by advertising it as MRT-Ineligible. Such a link will not be used on the MRT forwarding path for any destination. Advertising links as MRT-Ineligible is the main tool provided by MRT-FRR for keeping backup traffic off of lower bandwidth links during fast-reroute events.

MRT-FRR允许运营商通过宣传MRT不合格来排除MRT岛的链接,从而排除GADAG。这样的链接将不会在任何目的地的捷运转发路径上使用。MRT-FRR提供的主要工具是将链路广告为MRT不合格,以便在快速重路由事件期间阻止低带宽链路的备份流量。

Note that all of the backup paths produced by the MRT Lowpoint algorithm are closely tied to the common GADAG computed as part of that algorithm. Therefore, it is generally not possible to modify a subset of paths without affecting other paths. This precludes more fine-grained modification of individual backup paths when using only paths computed by the MRT Lowpoint algorithm.

请注意,MRT低点算法生成的所有备份路径都与作为该算法一部分计算的公共GADAG密切相关。因此,通常不可能在不影响其他路径的情况下修改路径子集。当仅使用由MRT Lowpoint算法计算的路径时,这就避免了对单个备份路径进行更细粒度的修改。

However, it may be desirable to allow an operator to use MRT-FRR alternates together with alternates provided by other FRR technologies. A policy-based alternate selection process can allow an operator to select the best alternate from those provided by MRT and other FRR technologies. As a concrete example, it may be desirable to implement a policy where a downstream LFA (if it exists for a given failure mode and destination) is preferred over a given MRT alternate. This combination gives the operator the ability to affect where traffic flows during a fast-reroute event, while still

然而,允许操作员将MRT-FRR替代品与其他FRR技术提供的替代品一起使用可能是可取的。基于策略的备选方案选择流程允许运营商从MRT和其他FRR技术提供的备选方案中选择最佳方案。作为一个具体的例子,可能需要实施一项政策,其中下游LFA(如果针对给定的故障模式和目的地存在)优先于给定的MRT备选方案。这种组合使运营商能够在快速重路由事件期间影响交通流的位置,同时

producing backup paths that use no additional labels for LDP traffic and will not loop under multiple failures. This and other choices of alternate selection policy can be evaluated in the context of their effect on fast-reroute traffic flow and available capacity, as well as other deployment considerations.

生成的备份路径不使用LDP流量的附加标签,并且在多次故障下不会循环。可根据其对快速重路由交通流和可用容量的影响以及其他部署考虑因素来评估此备选选择策略和其他备选选择策略。

Note that future documents may define MRT profiles in addition to the default profile defined here. Different MRT profiles will generally produce alternate paths with different properties. An implementation may allow an operator to use different MRT profiles instead of or in addition to the default profile.

注意,除了此处定义的默认配置文件外,未来的文档可能会定义MRT配置文件。不同的地铁线路通常会产生具有不同特性的备用路径。实施可能允许操作员使用不同的MRT配置文件,而不是默认配置文件,或者除了默认配置文件之外。

13.3. MRT IP Tunnel Loopback Address Management
13.3. MRT IP隧道环回地址管理

As described in Section 6.1.2, if an implementation uses IP tunneling as the mechanism to realize MRT forwarding paths, each node must advertise an MRT-Red and an MRT-Blue loopback address. These IP addresses must be unique within the routing domain to the extent that they do not overlap with each other or with any other routing table entries. It is expected that operators will use existing tools and processes for managing infrastructure IP addresses to manage these additional MRT-related loopback addresses.

如第6.1.2节所述,如果实现使用IP隧道作为实现MRT转发路径的机制,则每个节点必须公布MRT Red和MRT Blue环回地址。这些IP地址在路由域中必须是唯一的,以使它们彼此或与任何其他路由表项不重叠。预计运营商将使用现有工具和流程管理基础设施IP地址,以管理这些额外的MRT相关环回地址。

13.4. MRT-FRR in a Network with Degraded Connectivity
13.4. 连接降级的网络中的MRT-FRR

Ideally, routers in a service provider network using MRT-FRR will be initially deployed in a 2-connected topology, allowing MRT-FRR to find completely diverse paths to all destinations. However, a network can differ from an ideal 2-connected topology for many possible reasons, including network failures and planned maintenance events.

理想情况下,使用MRT-FRR的服务提供商网络中的路由器最初将部署在2连接拓扑中,从而允许MRT-FRR找到到所有目的地的完全不同的路径。但是,由于许多可能的原因,网络可能不同于理想的2连接拓扑,包括网络故障和计划维护事件。

MRT-FRR is designed to continue to function properly when network connectivity is degraded. When a network contains cut-vertices or cut-links dividing the network into different 2-connected blocks, MRT-FRR will continue to provide completely diverse paths for destinations within the same block as the PLR. For a destination in a different block from the PLR, the redundant paths created by MRT-FRR will be link and node diverse within each block, and the paths will only share links and nodes that are cut-links or cut-vertices in the topology.

MRT-FRR设计用于在网络连接降级时继续正常工作。当网络包含切割顶点或切割链路,将网络划分为不同的2连接块时,MRT-FRR将继续为PLR相同块内的目的地提供完全不同的路径。对于PLR不同块中的目的地,MRT-FRR创建的冗余路径将在每个块中具有不同的链路和节点,并且这些路径将仅共享作为拓扑中切割链路或切割顶点的链路和节点。

If a network becomes partitioned with one set of routers having no connectivity to another set of routers, MRT-FRR will function independently in each set of connected routers, providing redundant paths to destinations in same set of connected routers as a given PLR.

如果一个网络被一组与另一组路由器没有连接的路由器分割,MRT-FRR将在每一组连接的路由器中独立运行,提供到与给定PLR相同的连接路由器中的目的地的冗余路径。

13.5. Partial Deployment of MRT-FRR in a Network
13.5. 在网络中部分部署MRT-FRR

A network operator may choose to deploy MRT-FRR only on a subset of routers in an IGP area. MRT-FRR is designed to accommodate this partial deployment scenario. Only routers that advertise support for a given MRT profile will be included in a given MRT Island. For a PLR within the MRT Island, MRT-FRR will create redundant forwarding paths to all destinations with the MRT Island using maximally redundant trees all the way to those destinations. For destinations outside of the MRT Island, MRT-FRR creates paths to the destination that use forwarding state created by MRT-FRR within the MRT Island and shortest path forwarding state outside of the MRT Island. The paths created by MRT-FRR to non-Island destinations are guaranteed to be diverse within the MRT Island (if topologically possible). However, the part of the paths outside of the MRT Island may not be diverse.

网络运营商可选择仅在IGP区域的路由器子集上部署MRT-FRR。MRT-FRR旨在适应这种局部部署场景。只有宣传支持给定MRT配置文件的路由器才会包含在给定MRT岛中。对于MRT岛内的PLR,MRT-FRR将使用最大冗余树创建到所有目的地的冗余转发路径,并使用MRT岛到达所有目的地。对于MRT岛外的目的地,MRT-FRR使用MRT岛内MRT-FRR创建的转发状态和MRT岛外的最短路径转发状态创建到目的地的路径。MRT-FRR创建的通往非岛屿目的地的路径保证在MRT岛屿内具有多样性(如果拓扑可能)。然而,捷运岛外的部分道路可能并不多样化。

14. IANA Considerations
14. IANA考虑

IANA has created the "MRT Profile Identifier Registry". The range is 0 to 255. The Default MRT Profile defined in this document has value 0. Values 1-200 are allocated by Standards Action. Values 201-220 are for Experimental Use. Values 221-254 are for Private Use. Value 255 is reserved for future registry extension. (The allocation and use policies are described in [RFC5226].)

IANA已创建“MRT配置文件标识符注册表”。范围是0到255。此文档中定义的默认MRT配置文件的值为0。值1-200由标准行动分配。值201-220用于实验用途。值221-254仅供私人使用。值255保留用于将来的注册表扩展。(分配和使用策略见[RFC5226]。)

The initial registry is shown below.

初始注册表如下所示。

      Value    Description                               Reference
      -------  ----------------------------------------  ------------
      0        Default MRT Profile                       RFC 7812
      1-200    Unassigned
      201-220  Experimental Use
      221-254  Private Use
      255      Reserved (for future registry extension)
        
      Value    Description                               Reference
      -------  ----------------------------------------  ------------
      0        Default MRT Profile                       RFC 7812
      1-200    Unassigned
      201-220  Experimental Use
      221-254  Private Use
      255      Reserved (for future registry extension)
        

The "MRT Profile Identifier Registry" is a new registry in the IANA Matrix. Following existing conventions, http://www.iana.org/ protocols displays a new header: "Maximally Redundant Tree (MRT) Parameters". Under that header, there is an entry for "MRT Profile Identifier Registry", which links to the registry itself at http://www.iana.org/assignments/mrt-parameters.

“MRT配置文件标识符注册表”是IANA矩阵中的一个新注册表。按照现有公约,http://www.iana.org/ 协议显示一个新标题:“最大冗余树(MRT)参数”。在该标题下,有一个“MRT配置文件标识符注册表”条目,该条目链接到http://www.iana.org/assignments/mrt-parameters.

15. Security Considerations
15. 安全考虑

In general, MRT forwarding paths do not follow shortest paths. The transit forwarding state corresponding to the MRT paths is created during normal operations (before a failure occurs). Therefore, a malicious packet with an appropriate header injected into the network from a compromised location would be forwarded to a destination along a non-shortest path. When this technology is deployed, a network security design should not rely on assumptions about potentially malicious traffic only following shortest paths.

一般来说,捷运转发路径不遵循最短路径。与MRT路径对应的中转转发状态是在正常操作期间(发生故障之前)创建的。因此,具有适当报头的恶意数据包从受损位置注入网络,将沿着非最短路径转发到目的地。部署此技术时,网络安全设计不应依赖于仅遵循最短路径的潜在恶意流量假设。

It should be noted that the creation of non-shortest forwarding paths is not unique to MRT.

应该注意的是,非最短转发路径的创建不是MRT独有的。

MRT-FRR requires that routers advertise information used in the formation of MRT backup paths. While this document does not specify the protocol extensions used to advertise this information, we discuss security considerations related to the information itself. Injecting false MRT-related information could be used to direct some MRT backup paths over compromised transmission links. Combined with the ability to generate network failures, this could be used to send traffic over compromised transmission links during a fast-reroute event. In order to prevent this potential exploit, a receiving router needs to be able to authenticate MRT-related information that claims to have been advertised by another router.

MRT-FRR要求路由器公布用于形成MRT备份路径的信息。虽然本文档未指定用于公布此信息的协议扩展,但我们将讨论与信息本身相关的安全注意事项。注入虚假的MRT相关信息可用于引导某些MRT备份路径通过受损的传输链路。结合产生网络故障的能力,这可用于在快速重路由事件期间通过受损传输链路发送流量。为了防止这种潜在的攻击,接收路由器需要能够验证声称已被另一路由器通告的MRT相关信息。

16. References
16. 工具书类
16.1. Normative References
16.1. 规范性引用文件

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

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<http://www.rfc-editor.org/info/rfc2119>.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5226]Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 5226,DOI 10.17487/RFC5226,2008年5月<http://www.rfc-editor.org/info/rfc5226>.

[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. King, "LDP Extensions for Multi-Topology", RFC 7307, DOI 10.17487/RFC7307, July 2014, <http://www.rfc-editor.org/info/rfc7307>.

[RFC7307]Zhao,Q.,Raza,K.,Zhou,C.,Fang,L.,Li,L.,和D.King,“多拓扑的LDP扩展”,RFC 7307,DOI 10.17487/RFC7307,2014年7月<http://www.rfc-editor.org/info/rfc7307>.

[RFC7811] Enyedi, G., Ed., Csaszar, A., Atlas, A., Ed., Bowers, C., and A. Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, DOI 10.17487/RFC7811, June 2016, <http://www.rfc-editor.org/info/rfc7811>.

[RFC7811]Enyedi,G.,Ed.,Csaszar,A.,Atlas,A.,Ed.,Bowers,C.,和A.Gopalan,“使用最大冗余树计算IP/LDP快速重路由的算法(MRT-FRR)”,RFC 7811,DOI 10.17487/RFC78112016年6月<http://www.rfc-editor.org/info/rfc7811>.

16.2. Informative References
16.2. 资料性引用

[EnyediThesis] Enyedi, G., "Novel Algorithms for IP Fast Reroute", Department of Telecommunications and Media Informatics, Budapest University of Technology and Economics Ph.D. Thesis, February 2011, <https://repozitorium.omikk.bme.hu/bitstream/ handle/10890/1040/ertekezes.pdf>.

Enyedi,G,“IP快速重路由新算法”,布达佩斯技术与经济大学电信与媒体信息学系,博士。论文,2011年2月<https://repozitorium.omikk.bme.hu/bitstream/ handle/10890/1040/ertekezes.pdf>。

[LDP-MRT] Atlas, A., Tiruveedhula, K., Bowers, C., Tantsura, J., and IJ. Wijnands, "LDP Extensions to Support Maximally Redundant Trees", Work in Progress, draft-ietf-mpls-ldp-mrt-03, May 2016.

[LDP-MRT]Atlas,A.,Tiruveedhula,K.,Bowers,C.,Tantsura,J.,和IJ。Wijnands,“支持最大冗余树的LDP扩展”,正在进行的工作,草稿-ietf-mpls-LDP-mrt-03,2016年5月。

[MRT-ARCH] Atlas, A., Kebler, R., Wijnands, IJ., Csaszar, A., and G. Enyedi, "An Architecture for Multicast Protection Using Maximally Redundant Trees", Work in Progress, draft-atlas-rtgwg-mrt-mc-arch-02, July 2013.

[MRT-ARCH]Atlas,A.,Kebler,R.,Wijnands,IJ.,Csaszar,A.,和G.Enyedi,“使用最大冗余树的多播保护架构”,正在进行的工作,草稿-Atlas-rtgwg-MRT-mc-ARCH-022013年7月。

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.

[RFC2328]Moy,J.,“OSPF版本2”,STD 54,RFC 2328,DOI 10.17487/RFC2328,1998年4月<http://www.rfc-editor.org/info/rfc2328>.

[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.

[RFC4379]Kompella,K.和G.Swallow,“检测多协议标签交换(MPLS)数据平面故障”,RFC 4379,DOI 10.17487/RFC4379,2006年2月<http://www.rfc-editor.org/info/rfc4379>.

[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.

[RFC5286]Atlas,A.,Ed.和A.Zinin,Ed.,“IP快速重路由的基本规范:无环路交替”,RFC 5286,DOI 10.17487/RFC5286,2008年9月<http://www.rfc-editor.org/info/rfc5286>.

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <http://www.rfc-editor.org/info/rfc5331>.

[RFC5331]Aggarwal,R.,Rekhter,Y.,和E.Rosen,“MPLS上游标签分配和上下文特定标签空间”,RFC 5331,DOI 10.17487/RFC5331,2008年8月<http://www.rfc-editor.org/info/rfc5331>.

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.

[RFC5340]Coltun,R.,Ferguson,D.,Moy,J.,和A.Lindem,“IPv6的OSPF”,RFC 5340,DOI 10.17487/RFC5340,2008年7月<http://www.rfc-editor.org/info/rfc5340>.

[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, <http://www.rfc-editor.org/info/rfc5443>.

[RFC5443]Jork,M.,Atlas,A.,和L.Fang,“LDP IGP同步”,RFC 5443,DOI 10.17487/RFC5443,2009年3月<http://www.rfc-editor.org/info/rfc5443>.

[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <http://www.rfc-editor.org/info/rfc5714>.

[RFC5714]Shand,M.和S.Bryant,“IP快速重路由框架”,RFC 5714,DOI 10.17487/RFC5714,2010年1月<http://www.rfc-editor.org/info/rfc5714>.

[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, DOI 10.17487/RFC5715, January 2010, <http://www.rfc-editor.org/info/rfc5715>.

[RFC5715]Shand,M.和S.Bryant,“无环收敛框架”,RFC 5715DOI 10.17487/RFC57152010年1月<http://www.rfc-editor.org/info/rfc5715>.

[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., Francois, P., and O. Bonaventure, "Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 2013, <http://www.rfc-editor.org/info/rfc6976>.

[RFC6976]Shand,M.,Bryant,S.,Previdi,S.,Filsfils,C.,Francois,P.,和O.Bonaventure,“使用有序转发信息库(oFIB)方法的无循环收敛框架”,RFC 6976,DOI 10.17487/RFC6976,2013年7月<http://www.rfc-editor.org/info/rfc6976>.

[RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, DOI 10.17487/RFC6981, August 2013, <http://www.rfc-editor.org/info/rfc6981>.

[RFC6981]Bryant,S.,Previdi,S.,和M.Shand,“使用非经由地址的IP和MPLS快速重路由框架”,RFC 6981,DOI 10.17487/RFC69811913年8月<http://www.rfc-editor.org/info/rfc6981>.

[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, <http://www.rfc-editor.org/info/rfc6987>.

[RFC6987]Retana,A.,Nguyen,L.,Zinin,A.,White,R.,和D.McPherson,“OSPF存根路由器广告”,RFC 6987,DOI 10.17487/RFC6987,2013年9月<http://www.rfc-editor.org/info/rfc6987>.

[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <http://www.rfc-editor.org/info/rfc7490>.

[RFC7490]Bryant,S.,Filsfils,C.,Previdi,S.,Shand,M.,和N.So,“远程无环路备用(LFA)快速重路由(FRR)”,RFC 7490,DOI 10.17487/RFC74902015年4月<http://www.rfc-editor.org/info/rfc7490>.

Appendix A. Inter-level Forwarding Behavior for IS-IS
附录A.IS-IS的层间转发行为

In the description below, we use the terms "Level-1-only interface", "Level-2-only interface", and "Level-1-and-Level-2 interface" to mean an interface that has formed only a Level-1 adjacency, only a Level-2 adjacency, or both Level-1 and Level-2 adjacencies. Note that IS-IS also defines the concept of areas. A router is configured with an IS-IS area identifier, and a given router may be configured with multiple IS-IS area identifiers. For an IS-IS Level-1 adjacency to form between two routers, at least one IS-IS area identifier must match. IS-IS Level-2 adjacencies do not require any area identifiers to match. The behavior described below does not explicitly refer to IS-IS area identifiers. However, IS-IS area identifiers will indirectly affect the behavior by affecting the formation of Level-1 adjacencies.

在下面的描述中,我们使用术语“仅1级接口”、“仅2级接口”和“1级和2级接口”来表示仅形成1级邻接、仅形成2级邻接或同时形成1级和2级邻接的接口。注意IS-IS还定义了面积的概念。路由器配置有is-is区域标识符,并且给定路由器可以配置有多个is-is区域标识符。要在两个路由器之间形成IS-IS 1级邻接,必须至少有一个IS-IS区域标识符匹配。IS-IS 2级邻接不需要任何区域标识符来匹配。下面描述的行为没有明确引用IS-IS区域标识符。但是,IS-IS区域标识符将通过影响1级邻接的形成间接影响行为。

First, consider a packet destined to Z on MRT-Red or MRT-Blue received on a Level-1-only interface. If the best shortest path route to Z was learned from a Level-1 advertisement, then the packet should continue to be forwarded along MRT-Red or MRT-Blue. If, instead, the best route was learned from a Level-2 advertisement, then the packet should be removed from MRT-Red or MRT-Blue and forwarded on the shortest-path default forwarding topology.

首先,考虑在一个级别为1的接口上接收到MRT Red或MRT Blue的数据包。如果到Z的最佳最短路径是从一级广告中得知的,则数据包应继续沿MRT Red或MRT Blue转发。相反,如果从2级广告中学习到最佳路由,则应将数据包从MRT Red或MRT Blue中移除,并在最短路径默认转发拓扑上转发。

Now consider a packet destined to Z on MRT-Red or MRT-Blue received on a Level-2-only interface. If the best route to Z was learned from a Level-2 advertisement, then the packet should continue to be forwarded along MRT-Red or MRT-Blue. If, instead, the best route was learned from a Level-1 advertisement, then the packet should be removed from MRT-Red or MRT-Blue and forwarded on the shortest-path default forwarding topology.

现在考虑一个数据包到Z上的MRT Red或MRT Blue在一个2级的接口上接收。如果到Z的最佳路线是从2级广告中得知的,则数据包应继续沿MRT Red或MRT Blue转发。相反,如果从1级广告中学习到最佳路由,则应将数据包从MRT Red或MRT Blue中移除,并在最短路径默认转发拓扑上转发。

Finally, consider a packet destined to Z on MRT-Red or MRT-Blue received on a Level-1-and-Level-2 interface. This packet should continue to be forwarded along MRT-Red or MRT-Blue, regardless of which level the route was learned from.

最后,考虑在一个1级和2级接口上接收到MRT Red或MRT Blue的数据包。此数据包应继续沿MRT Red或MRT Blue转发,无论从哪个级别学习路由。

An implementation may simplify the decision-making process above by using the interface of the next hop for the route to Z to determine the level from which the best route to Z was learned. If the next hop points out a Level-1-only interface, then the route was learned from a Level-1 advertisement. If the next hop points out a Level-2-only interface, then the route was learned from a Level-2 advertisement. A next hop that points out a Level-1-and-Level-2 interface does not provide enough information to determine the source of the best route. With this simplification, an implementation would need to continue forwarding along MRT-Red or MRT-Blue when the next-hop points out a Level-1-and-Level-2 interface. Therefore, a packet

通过使用到Z的路由的下一跳的接口来确定到Z的最佳路由的学习级别,实现可以简化上述决策过程。如果下一跳指向仅1级的接口,则路由是从1级公告中学习的。如果下一跳指向仅2级的接口,则路由是从2级公告中学习的。指出1级和2级接口的下一跳没有提供足够的信息来确定最佳路由的来源。通过这种简化,当下一个跃点指出1级和2级接口时,实现将需要继续沿MRT Red或MRT Blue转发。因此,一个包

on MRT-Red or MRT-Blue going from Level-1 to Level-2 (or vice versa) that traverses a Level-1-and-Level-2 interface in the process will remain on MRT-Red or MRT-Blue. This simplification may not always produce the optimal forwarding behavior, but it does not introduce interoperability problems. The packet will stay on an MRT backup path longer than necessary, but it will still reach its destination.

在MRT红色或MRT蓝色上,从1级到2级(或反之亦然),在流程中穿过1级和2级接口的将保持MRT红色或MRT蓝色。这种简化可能并不总是产生最佳的转发行为,但它不会带来互操作性问题。数据包在MRT备份路径上停留的时间将超过必要的时间,但仍将到达其目的地。

Appendix B. General Issues with Area Abstraction
附录B.区域抽象的一般问题

When a multihomed prefix is connected in two different areas, it may be impractical to protect them without adding the complexity of explicit tunneling. This is also a problem for LFA and Remote-LFA.

当多址前缀连接到两个不同的区域时,在不增加显式隧道的复杂性的情况下保护它们可能是不切实际的。这也是LFA和远程LFA的问题。

          50
        |----[ASBR Y]---[B]---[ABR 2]---[C]      Backbone Area 0:
        |                                |           ABR 1, ABR 2, C, D
        |                                |
        |                                |       Area 20:  A, ASBR X
        |                                |
        p ---[ASBR X]---[A]---[ABR 1]---[D]      Area 10: B, ASBR Y
           5                                  p is a Type 1 AS-external
        
          50
        |----[ASBR Y]---[B]---[ABR 2]---[C]      Backbone Area 0:
        |                                |           ABR 1, ABR 2, C, D
        |                                |
        |                                |       Area 20:  A, ASBR X
        |                                |
        p ---[ASBR X]---[A]---[ABR 1]---[D]      Area 10: B, ASBR Y
           5                                  p is a Type 1 AS-external
        

Figure 4: AS External Prefixes in Different Areas

图4:作为不同区域中的外部前缀

Consider the network in Figure 4 and assume there is a richer connective topology that isn't shown, where the same prefix is announced by ASBR X and ASBR Y, which are in different non-backbone areas. If the link from A to ASBR X fails, then an MRT alternate could forward the packet to ABR 1 and ABR 1 could forward it to D, but then D would find the shortest route is back via ABR 1 to Area 20. This problem occurs because the routers, including the ABR, in one area are not yet aware of the failure in a different area.

考虑图4中的网络,假设有一个更丰富的连接拓扑没有显示,其中相同的前缀由ASBR X和ASBR Y宣布,它们位于不同的非骨干区域。如果从A到ASBR X的链路失败,那么MRT候补者可以将数据包转发给ABR 1,ABR 1可以将其转发给D,但D会发现最短的路由是通过ABR 1返回到区域20。发生此问题是因为一个区域中的路由器(包括ABR)尚未意识到另一个区域中的故障。

The only way to get it from A to ASBR Y is to explicitly tunnel it to ASBR Y. If the traffic is unlabeled or the appropriate MPLS labels are known, then explicit tunneling MAY be used as long as the shortest path of the tunnel avoids the failure point. In that case, A must determine that it should use an explicit tunnel instead of an MRT alternate.

从A到ASBR Y的唯一方法是显式地将其隧道到ASBR Y。如果流量未标记或知道适当的MPLS标签,则可以使用显式隧道,只要隧道的最短路径避免故障点。在这种情况下,A必须确定它应该使用明确的隧道,而不是地铁候补。

Acknowledgements

致谢

The authors would like to thank Mike Shand for his valuable review and contributions.

作者要感谢Mike Shand的宝贵评论和贡献。

The authors would like to thank Joel Halpern, Hannes Gredler, Ted Qian, Kishore Tiruveedhula, Shraddha Hegde, Santosh Esale, Nitin Bahadur, Harish Sitaraman, Raveendra Torvi, Anil Kumar SN, Bruno Decraene, Eric Wu, Janos Farkas, Rob Shakir, Stewart Bryant, and Alvaro Retana for their suggestions and review.

作者要感谢Joel Halpern、Hannes Gredler、Ted Qian、Kishore Tiruveedhula、Shraddha Hegde、Santosh Esale、Nitin Bahadur、Harish Sitaraman、Ravendra Torvi、Anil Kumar SN、Bruno Decaene、Eric Wu、Janos Farkas、Rob Shakir、Stewart Bryant和Alvaro Retana的建议和评论。

Contributors

贡献者

Robert Kebler Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States Email: rkebler@juniper.net

Robert Kebler Juniper Networks 10 Technology Park Drive Westford,马萨诸塞州01886美国电子邮件:rkebler@juniper.net

Andras Csaszar Ericsson Konyves Kalman krt 11 Budapest 1097 Hungary Email: Andras.Csaszar@ericsson.com

Andras Csaszar Ericsson Konyves Kalman krt 11布达佩斯1097匈牙利电子邮件:Andras。Csaszar@ericsson.com

Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 United States Email: jeff.tantsura@ericsson.com

Jeff Tantsura Ericsson加利福尼亚州圣何塞霍尔格大道300号,邮编95134美国电子邮件:Jeff。tantsura@ericsson.com

Russ White VCE Email: russw@riw.us

Russ White VCE电子邮件:russw@riw.us

Authors' Addresses

作者地址

Alia Atlas Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States

美国马萨诸塞州韦斯特福德科技园大道10号Alia Atlas Juniper Networks 01886

   Email: akatlas@juniper.net
        
   Email: akatlas@juniper.net
        

Chris Bowers Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States

Chris Bowers Juniper Networks 1194 N.Mathilda Ave.Sunnyvale,加利福尼亚州94089

   Email: cbowers@juniper.net
        
   Email: cbowers@juniper.net
        

Gabor Sandor Enyedi Ericsson Konyves Kalman krt 11. Budapest 1097 Hungary

加博·桑多尔·恩耶迪·爱立信·科尼维斯·卡尔曼krt 11。布达佩斯1097匈牙利

   Email: Gabor.Sandor.Enyedi@ericsson.com
        
   Email: Gabor.Sandor.Enyedi@ericsson.com