Internet Engineering Task Force (IETF) H. Chen, Ed.
Request for Comments: 8424 Huawei Technologies
Category: Experimental R. Torvi, Ed.
ISSN: 2070-1721 Juniper Networks
August 2018
Internet Engineering Task Force (IETF) H. Chen, Ed.
Request for Comments: 8424 Huawei Technologies
Category: Experimental R. Torvi, Ed.
ISSN: 2070-1721 Juniper Networks
August 2018
Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection
用于标签交换路径（LSP）入口快速重路由（FRR）保护的RSVP-TE扩展
Abstract
摘要
This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). It extends the Fast Reroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental.
本文档描述了资源预留协议-流量工程（RSVP-TE）的扩展，用于本地保护点对点（P2P）或点对多点（P2MP）流量工程（TE）标签交换路径（LSP）的入口节点。它将LSP传输节点的快速重路由（FRR）保护扩展到LSP的入口节点。本文件中描述的程序是实验性的。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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 https://www.rfc-editor.org/info/rfc8424.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8424.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Ingress Local Protection Example . . . . . . . . . . . . 5
1.2. Ingress Local Protection Overview . . . . . . . . . . . . 6
2. Conventions Used in This Document . . . . . . . . . . . . . . 7
3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 7
3.1. Source Detects Failure . . . . . . . . . . . . . . . . . 7
3.2. Backup and Source Detect Failure . . . . . . . . . . . . 8
4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 9
4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 9
5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 9
5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 10
5.1.1. Class Number and Class Type . . . . . . . . . . . . . 10
5.1.2. Object Format . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Subobject: Backup Ingress IPv4 Address . . . . . . . 12
5.1.4. Subobject: Backup Ingress IPv6 Address . . . . . . . 13
5.1.5. Subobject: Ingress IPv4 Address . . . . . . . . . . . 13
5.1.6. Subobject: Ingress IPv6 Address . . . . . . . . . . . 13
5.1.7. Subobject: TRAFFIC_DESCRIPTOR . . . . . . . . . . . . 14
5.1.8. Subobject: Label-Routes . . . . . . . . . . . . . . . 15
6. Behavior of Ingress Protection . . . . . . . . . . . . . . . 15
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . 15
6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . 16
6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . 17
6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . 17
6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . 18
6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 19
6.3.1. Backup Ingress Behavior in the Off-Path Case . . . . 20
6.3.2. Backup Ingress Behavior in the On-Path Case . . . . . 22
6.3.3. Failure Detection and Refresh PATH Messages . . . . . 23
6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . 23
6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 24
6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Ingress Local Protection Example . . . . . . . . . . . . 5
1.2. Ingress Local Protection Overview . . . . . . . . . . . . 6
2. Conventions Used in This Document . . . . . . . . . . . . . . 7
3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 7
3.1. Source Detects Failure . . . . . . . . . . . . . . . . . 7
3.2. Backup and Source Detect Failure . . . . . . . . . . . . 8
4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 9
4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 9
5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 9
5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 10
5.1.1. Class Number and Class Type . . . . . . . . . . . . . 10
5.1.2. Object Format . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Subobject: Backup Ingress IPv4 Address . . . . . . . 12
5.1.4. Subobject: Backup Ingress IPv6 Address . . . . . . . 13
5.1.5. Subobject: Ingress IPv4 Address . . . . . . . . . . . 13
5.1.6. Subobject: Ingress IPv6 Address . . . . . . . . . . . 13
5.1.7. Subobject: TRAFFIC_DESCRIPTOR . . . . . . . . . . . . 14
5.1.8. Subobject: Label-Routes . . . . . . . . . . . . . . . 15
6. Behavior of Ingress Protection . . . . . . . . . . . . . . . 15
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . 15
6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . 16
6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . 17
6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . 17
6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . 18
6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 19
6.3.1. Backup Ingress Behavior in the Off-Path Case . . . . 20
6.3.2. Backup Ingress Behavior in the On-Path Case . . . . . 22
6.3.3. Failure Detection and Refresh PATH Messages . . . . . 23
6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . 23
6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 24
6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
For an MPLS Traffic Engineered (TE) Label Switched Path (LSP), protecting the failures of its transit nodes using Fast Reroute (FRR) is covered in [RFC4090] for Point-to-Point (P2P) LSPs and [RFC4875] for Point-to-Multipoint (P2MP) LSPs. However, protecting the failure of its ingress node using FRR is not covered in either [RFC4090] or [RFC4875]. The MPLS Transport Profile (MPLS-TP) Linear Protection described in [RFC6378] can provide a protection against the failure of any transit node of an LSP between the ingress node and the egress node of the LSP, but it cannot protect against the failure of the ingress node.
对于MPLS流量工程（TE）标签交换路径（LSP），[RFC4090]对点对点（P2P）LSP和[RFC4875]对点对多点（P2MP）LSP介绍了使用快速重路由（FRR）保护其传输节点的故障。但是，[RFC4090]或[RFC4875]均未涉及使用FRR保护其入口节点的故障。[RFC6378]中描述的MPLS传输配置文件（MPLS-TP）线性保护可以针对LSP的入口节点和出口节点之间的LSP的任何传输节点的故障提供保护，但不能针对入口节点的故障提供保护。
To protect against the failure of the (primary) ingress node of a primary end-to-end P2MP (or P2P) TE LSP, a typical existing solution is to set up a secondary backup end-to-end P2MP (or P2P) TE LSP. The backup LSP is from a backup ingress node to backup egress nodes (or node). The backup ingress node is different from the primary ingress node. The backup egress nodes (or node) are (or is) different from the primary egress nodes (or node) of the primary LSP. For a P2MP TE LSP, on each of the primary (and backup) egress nodes, a P2P LSP is created from the egress node to its primary (backup) ingress node and configured with Bidirectional Forwarding Detection (BFD). This is used to detect the failure of the primary (backup) ingress node for the receiver to switch to the backup (or primary) egress node to receive the traffic after the primary (or backup) ingress node fails when both the primary LSP and the secondary LSP carry the traffic. In addition, FRR may be used to provide protections against the failures of the transit nodes and the links of the primary and secondary end-to-end TE LSPs.
为了防止主端到端P2MP（或P2P）TE LSP的（主）入口节点出现故障，一个典型的现有解决方案是设置辅助备份端到端P2MP（或P2P）TE LSP。备份LSP从备份入口节点到备份出口节点（或节点）。备份入口节点与主入口节点不同。备份出口节点（或节点）与主LSP的主出口节点（或节点）不同。对于P2MP TE LSP，在每个主（和备份）出口节点上，从出口节点到其主（备份）入口节点创建P2P LSP，并配置双向转发检测（BFD）。这用于检测主（或备份）入口节点的故障，以便在主（或备份）入口节点发生故障后，当主LSP和辅助LSP都承载流量时，接收器切换到备份（或主）出口节点以接收流量。此外，FRR可用于针对传输节点和主要和次要端到端TE LSP链路的故障提供保护。
There are a number of issues in this solution:
此解决方案中存在许多问题：
o It consumes lots of network resources. Double states need to be maintained in the network since two end-to-end TE LSPs are created. Double link bandwidth is reserved and used when both the primary and the secondary end-to-end TE LSPs carry the traffic at the same time.
o 它消耗了大量的网络资源。由于创建了两个端到端TE LSP，因此需要在网络中保持双状态。当主要和次要端到端TE LSP同时承载流量时，保留并使用双链路带宽。
o More operations are needed, which include the configuration of two end-to-end TE LSPs and BFDs from each of the egress nodes to its corresponding ingress node.
o 需要更多的操作，包括从每个出口节点到其对应的入口节点的两个端到端TE lsp和bfd的配置。
o The detection of the failure of the ingress node may not be reliable. Any failure on the path of the BFD from an egress node to an ingress node may cause the BFD to indicate the failure of the ingress node.
o 入口节点故障的检测可能不可靠。从出口节点到入口节点的BFD路径上的任何故障都可能导致BFD指示入口节点的故障。
o The speed of protection against the failure of the ingress node may be slow.
o 针对入口节点故障的保护速度可能较慢。
This specification defines a simple extension to RSVP-TE for local protection (FRR) of the ingress node of a P2MP or P2P LSP to resolve these issues. Ingress local protection and ingress FRR protection will be used interchangeably.
本规范定义了RSVP-TE的简单扩展，用于P2MP或P2P LSP入口节点的本地保护（FRR），以解决这些问题。入口局部保护和入口FRR保护将互换使用。
Note that this document is an Experimental RFC. Two different approaches are proposed to transfer the information for ingress protection. They both use the same new INGRESS_PROTECTION object, which is sent in both PATH and RESV messages between a primary ingress and a backup ingress. One approach is the Relay-Message Method (refer to Sections 6.1.1 and 6.2.1), the other is the Proxy-Ingress Method (refer to Sections 6.1.2 and 6.2.2). Each of them has advantages and disadvantages. It is hard to decide which one is used as a standard approach now. It is expected that the experiment on the ingress local protection with these two approaches will provide quantities to help choose one. The quantities include the numbers on control traffic, states, codes, and operations. After one approach is selected, the document will be revised to reflect that selection and any other items learned from the experiment. The revised document is expected to be submitted for publication on the standards track.
请注意，本文档是一个实验性RFC。提出了两种不同的方法来传输用于入口保护的信息。它们都使用相同的新入口保护对象，该对象在主入口和备份入口之间的PATH和RESV消息中发送。一种方法是中继消息方法（参考第6.1.1节和第6.2.1节），另一种方法是代理入口方法（参考第6.1.2节和第6.2.2节）。它们各有优缺点。现在很难决定哪种方法是标准方法。预计采用这两种方法进行的入口局部保护试验将提供数量，以帮助选择一种方法。数量包括控制流量、状态、代码和操作的编号。选择一种方法后，将对文件进行修改，以反映该选择和从实验中学到的任何其他项目。修订后的文件预计将在标准轨道上提交出版。
Figure 1 shows an example of using a backup P2MP LSP to locally protect the ingress of a primary P2MP LSP, which is from ingress Ia to three egresses: L1, L2, and L3. The backup LSP is from backup ingress Ib to the next hops of ingress Ia: R2 and R4.
图1显示了使用备份P2MP LSP本地保护主P2MP LSP入口的示例，主P2MP LSP从入口Ia到三个出口：L1、L2和L3。备份LSP从备份入口Ib到入口Ia的下一个跃点：R2和R4。
******* ******* S Source
[R2]-----[R3]-----[L1] Ix Ingress
*/ & Rx Transit
*/ & Lx Egress
*/ & *** Primary LSP
*/ & &&& Backup LSP across
*/ & Logical Hop
*/ &
*/ ******** ******** *******
[S]---[Ia]--------[R4]------[R5]-----[L2]
\ | & & *\
\ | & & *\
\ | & & *\
\ | & & *\
\ | & & *\
\ |& & *\
[Ib]&&& [L3]
******* ******* S Source
[R2]-----[R3]-----[L1] Ix Ingress
*/ & Rx Transit
*/ & Lx Egress
*/ & *** Primary LSP
*/ & &&& Backup LSP across
*/ & Logical Hop
*/ &
*/ ******** ******** *******
[S]---[Ia]--------[R4]------[R5]-----[L2]
\ | & & *\
\ | & & *\
\ | & & *\
\ | & & *\
\ | & & *\
\ |& & *\
[Ib]&&& [L3]
Figure 1: Ingress Local Protection
图1：入口局部保护
In normal operations, source S sends the traffic to primary ingress Ia. Ia imports the traffic into the primary LSP.
在正常操作中，源S向主入口Ia发送流量。Ia将流量导入主LSP。
When source S detects the failure of Ia, it switches the traffic to backup ingress Ib, which imports the traffic from S into the backup LSP to Ia's next hops, R2 and R4, where the traffic is merged into the primary LSP and then sent to egresses L1, L2, and L3.
当源S检测到Ia故障时，它将通信量切换到备份入口Ib，备份入口Ib将通信量从S导入备份LSP到Ia的下一个跃点R2和R4，其中通信量合并到主LSP，然后发送到出口L1、L2和L3。
Note that the backup ingress is one logical hop away from the ingress. A logical hop is a direct link or a tunnel (such as a GRE tunnel) over which RSVP-TE messages may be exchanged.
请注意，备份入口距离入口只有一个逻辑跃点。逻辑跃点是可在其上交换RSVP-TE消息的直接链路或隧道（例如GRE隧道）。
There are four parts in ingress local protection:
入口局部保护包括四个部分：
o setting up the necessary backup LSP forwarding state based on the information received for ingress local protection;
o 基于接收到的用于入口本地保护的信息，设置必要的备份LSP转发状态；
o detecting the primary ingress failure and providing the fast repair (as discussed in Sections 3 and 4);
o 检测主入口故障并提供快速维修（如第3节和第4节所述）；
o maintaining the RSVP-TE control-plane state until a global repair is done; and,
o 保持RSVP-TE控制平面状态，直到完成全局修复；和
o performing the global repair (see Section 6.4.2).
o 执行整体维修（见第6.4.2节）。
The primary ingress of a primary LSP sends the backup ingress the information for ingress protection in a PATH message with a new INGRESS_PROTECTION object. The backup ingress sets up the backup LSP(s) and forwarding state after receiving the necessary information for ingress protection. Then, it sends the primary ingress the status of ingress protection in a RESV message with a new INGRESS_PROTECTION object.
主LSP的主入口使用新的入口保护对象在PATH消息中向备份入口发送入口保护信息。备份入口在接收到入口保护所需的信息后，设置备份LSP和转发状态。然后，它向主入口发送带有新入口保护对象的RESV消息中的入口保护状态。
When the primary ingress fails, the backup ingress sends or refreshes the next hops of the primary ingress the PATH messages without any INGRESS_PROTECTION object after verifying the failure. Thus, the RSVP-TE control-plane state of the primary LSP is maintained.
当主入口失败时，备份入口在验证失败后发送或刷新主入口的下一个跃点路径消息，而不使用任何入口保护对象。因此，保持主LSP的RSVP-TE控制平面状态。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Exactly how to detect the failure of the ingress is out of scope. However, it is necessary to discuss different modes for detecting the failure because they determine what is the required behavior for the source and backup ingress.
如何准确检测入口故障超出了范围。但是，有必要讨论检测故障的不同模式，因为它们确定源和备份入口所需的行为。
Source Detects Failure, or Source-Detect for short, means that the source is responsible for "fast detecting" the failure of the primary ingress of an LSP. Fast detecting the failure means detecting the failure in a few or tens of milliseconds. The backup ingress is ready to import the traffic from the source into the backup LSP(s) after the backup LSP(s) is up.
Source Detect Failure，简称Source Detect，表示源负责“快速检测”LSP主入口的故障。快速检测故障意味着在几毫秒或几十毫秒内检测到故障。备份入口准备在备份LSP启动后将流量从源导入备份LSP。
In normal operations, the source sends the traffic to the primary ingress. When the source detects the failure of the primary ingress, it switches the traffic to the backup ingress, which delivers the traffic to the next hops of the primary ingress through the backup LSP(s), where the traffic is merged into the primary LSP.
在正常操作中，源向主入口发送流量。当源检测到主入口故障时，它将通信量切换到备份入口，备份入口通过备份LSP将通信量传送到主入口的下一个跃点，其中通信量合并到主LSP中。
For an LSP, after the primary ingress fails, the backup ingress MUST use a method to verify the failure of the primary ingress before the PATH message for the LSP expires at the next hop of the primary ingress. After verifying the failure, the backup ingress sends/
对于LSP，在主入口失败后，备份入口必须在LSP的PATH消息在主入口的下一跳过期之前使用方法验证主入口的失败。验证故障后，备份入口发送/
refreshes the PATH message to the next hop through the backup LSP as needed. The method may verify the failure of the primary ingress slowly, such as in seconds.
根据需要通过备份LSP将路径消息刷新到下一个跃点。该方法可以缓慢地验证主入口的故障，例如以秒为单位。
After the primary ingress fails, it will not be reachable after routing convergence. Thus, checking whether the primary ingress (address) is reachable is a possible method.
主入口失败后，路由收敛后将无法访问。因此，检查主入口（地址）是否可到达是一种可能的方法。
When the previously failed primary ingress of a primary LSP becomes available again and the primary LSP has recovered from its primary ingress, the source may switch the traffic to the primary ingress from the backup ingress. An operator may control the traffic switch through using a command on the source node after seeing that the primary LSP has recovered.
当主LSP先前失败的主入口再次可用且主LSP已从其主入口恢复时，源可将通信量从备份入口切换到主入口。操作员可以在看到主LSP已恢复后，通过使用源节点上的命令来控制业务交换机。
Backup and Source Detect Failure, or Backup-Source-Detect for short, means that both the backup ingress and the source are concurrently responsible for fast detecting the failure of the primary ingress.
备份和源检测故障，简称备份源检测，意味着备份入口和源同时负责快速检测主入口的故障。
Note that one of the differences between Source-Detect and Backup-Source-Detect is the following: in the former, the backup ingress verifies the failure of the primary ingress slowly, such as in seconds; in the latter, the backup ingress detects the failure fast, such as in a few or tens of milliseconds.
请注意，源检测和备份源检测之间的区别之一如下：在前者中，备份入口缓慢地验证主入口的故障，例如以秒为单位；在后者中，备份入口快速检测故障，例如在几毫秒或几十毫秒内。
In normal operations, the source sends the traffic to the primary ingress. It switches the traffic to the backup ingress when it detects the failure of the primary ingress.
在正常操作中，源向主入口发送流量。当检测到主入口故障时，它将流量切换到备用入口。
The backup ingress does not import any traffic from the source into the backup LSP in normal operations. When it detects the failure of the primary ingress, it imports the traffic from the source into the backup LSP to the next hops of the primary ingress, where the traffic is merged into the primary LSP.
在正常操作中，备份入口不会将任何流量从源导入备份LSP。当检测到主入口故障时，它将流量从源导入备份LSP到主入口的下一个跃点，其中流量合并到主LSP中。
The Source-Detect is preferred. It is simpler than the Backup-Source-Detect, which needs both the source and the backup ingress to detect the ingress failure quickly.
首选源检测。它比备份源检测更简单，后者需要源和备份入口来快速检测入口故障。
Before the primary ingress fails, the backup ingress is responsible for creating the necessary backup LSPs. These LSPs might be multiple bypass P2P LSPs that avoid the ingress. Alternately, the backup ingress could choose to use a single backup P2MP LSP as a bypass or detour to protect the primary ingress of a primary P2MP LSP.
在主入口失败之前，备份入口负责创建必要的备份LSP。这些LSP可能是避免进入的多个旁路P2P LSP。或者，备份入口可以选择使用单个备份P2MP LSP作为旁路或迂回，以保护主P2MP LSP的主入口。
The backup ingress may be "off path" or "on path" of an LSP. If a backup ingress is not any node of the LSP, it is off path. If a backup ingress is a next hop of the primary ingress of the LSP, it is on path. When a backup ingress for protecting the primary ingress is configured, the backup ingress MUST not be on the LSP except for if it is the next hop of the primary ingress. If it is on path, the primary forwarding state associated with the primary LSP SHOULD be clearly separated from the backup LSP(s) state.
备份入口可以是LSP的“非路径”或“路径上”。如果备份入口不是LSP的任何节点，则它是非路径的。若备份入口是LSP主入口的下一个跃点，则它位于路径上。配置用于保护主入口的备份入口时，除非是主入口的下一跳，否则备份入口不得位于LSP上。如果在路径上，则与主LSP关联的主转发状态应与备份LSP状态明确分开。
A forwarding entry for a backup LSP is created on the backup ingress after the LSP is set up. Depending on the failure-detection mode (e.g., Source-Detect), it may be used to forward received traffic or simply be inactive (e.g., Backup-Source-Detect) until required. In either case, when the primary ingress fails, this entry is used to import the traffic into the backup LSP to the next hops of the primary ingress, where the traffic is merged into the primary LSP.
设置LSP后，将在备份入口上创建备份LSP的转发条目。根据故障检测模式（例如，源检测），它可用于转发接收到的通信量，或只是在需要之前处于非活动状态（例如，备份源检测）。在任何一种情况下，当主入口失败时，此条目用于将流量导入到备份LSP中，以到达主入口的下一个跃点，其中流量合并到主LSP中。
The forwarding entry for a backup LSP is a local implementation issue. In one device, it may have an inactive flag. This inactive forwarding entry is not used to forward any traffic normally. When the primary ingress fails, it is changed to active; thus, the traffic from the source is imported into the backup LSP.
备份LSP的转发条目是本地实现问题。在一个设备中，它可能有一个非活动标志。此非活动转发条目通常不用于转发任何流量。当主入口失败时，它变为活动；因此，来自源的通信量被导入到备份LSP中。
A new object, INGRESS_PROTECTION, is defined for signaling ingress local protection. The primary ingress of a primary LSP sends the backup ingress this object in a PATH message. In this case, the object contains the information needed to set up ingress protection. The information includes:
定义了一个新对象，即入口保护，用于发送入口本地保护信号。主LSP的主入口通过PATH消息向该对象发送备份入口。在这种情况下，对象包含设置入口保护所需的信息。这些资料包括：
o the Backup Ingress IP Address, which indicates the backup ingress;
o 备份入口IP地址，表示备份入口；
o the TRAFFIC_DESCRIPTOR, which describes the traffic that the primary LSP transports (this traffic is imported into the backup LSP(s) on the backup ingress when the primary ingress fails);
o 通信量_描述符，描述主LSP传输的通信量（当主入口失败时，此通信量导入备份入口上的备份LSP）；
o the Labels and Routes, which indicate the first hops of the primary LSP, each of which is paired with its label; and,
o 标签和路由，其指示主LSP的第一跳，每个跳与其标签成对；和
o the Desire options on ingress protection, such as a P2MP option, which indicates a desire to use a backup P2MP LSP to protect the primary ingress of a primary P2MP LSP.
o 入口保护的期望选项，如P2MP选项，表示希望使用备份P2MP LSP来保护主P2MP LSP的主入口。
The backup ingress sends the primary ingress this object in a RESV message. In this case, the object contains the information about the status on the ingress protection.
备份入口在RESV消息中向该对象发送主入口。在这种情况下，对象包含有关入口保护状态的信息。
The Class Number for the INGRESS_PROTECTION object MUST be of the form 0bbbbbbb to enable implementations that do not recognize the object to reject the entire message and return an "Unknown Object Class" error [RFC2205]. It is suggested that a Class Number value from the Private Use range (124-127) [RFC3936] specified for the 0bbbbbbb octet be chosen for this experiment. It is also suggested that a Class Type value of 1 be used for this object in this experiment.
INGRESS_保护对象的类号必须为0BBB格式，以使不识别该对象的实现能够拒绝整个消息并返回“未知对象类”错误[RFC2205]。建议在本实验中选择为0bbb八位组指定的专用范围（124-127）[RFC3936]中的类别编号值。在本实验中，还建议对该对象使用类类型值1。
The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH message is used to control the backup for protecting the primary ingress of a primary LSP. The primary ingress MUST insert this object into the PATH message to be sent to the backup ingress for protecting the primary ingress.
路径消息中带有快速重路由对象的入口保护对象用于控制备份，以保护主LSP的主入口。主入口必须将此对象插入要发送到备份入口的路径消息中，以保护主入口。
The INGRESS_PROTECTION object has the following format:
入口保护对象具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (bytes) | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (zero) | NUB | Flags | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ (Subobjects) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (bytes) | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (zero) | NUB | Flags | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ (Subobjects) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags 0x01 Ingress local protection available 0x02 Ingress local protection in use 0x04 Bandwidth protection
标志0x01入口本地保护可用0x02入口本地保护正在使用0x04带宽保护
Options 0x01 Revert to Ingress 0x02 P2MP Backup
选项0x01还原为入口0x02 P2MP备份
For protecting the ingress of a P2MP LSP, if the backup ingress doesn't have a backup LSP to each of the next hops of the primary ingress, it SHOULD clear "Ingress local protection available" and set the Number of Unprotected Branches (NUB) to the number of the next hops to which there is no backup LSP.
为了保护P2MP LSP的入口，如果备份入口没有到主入口的每个下一个跃点的备份LSP，则应清除“入口本地保护可用”，并将未受保护分支（NUB）的数量设置为没有备份LSP的下一个跃点的数量。
The flags are used to communicate status information from the backup ingress to the primary ingress.
这些标志用于将状态信息从备份入口传送到主入口。
o Ingress local protection available: The backup ingress MUST set this flag after backup LSPs are up and ready for locally protecting the primary ingress. The backup ingress sends this to the primary ingress to indicate that the primary ingress is locally protected.
o 入口本地保护可用：备份入口必须在备份LSP启动并准备好本地保护主入口后设置此标志。备份入口将其发送到主入口，以指示主入口受到本地保护。
o Ingress local protection in use: The backup ingress MUST set this flag when it detects a failure in the primary ingress and actively redirects the traffic into the backup LSPs. The backup ingress records this flag and does not send any RESV messages with this flag to the primary ingress since the primary ingress is down.
o 正在使用入口本地保护：当备份入口检测到主入口故障并主动将流量重定向到备份LSP时，必须设置此标志。备份入口记录此标志，并且不会向主入口发送带有此标志的任何RESV消息，因为主入口已关闭。
o Bandwidth protection: The backup ingress MUST set this flag if the backup LSPs guarantee to provide the desired bandwidth for the protected LSP against the primary ingress failure.
o 带宽保护：如果备份LSP保证针对主入口故障为受保护LSP提供所需带宽，则备份入口必须设置此标志。
The options are used by the primary ingress to specify the desired behavior to the backup ingress.
主入口使用这些选项来指定备份入口的所需行为。
o Revert to Ingress: The primary ingress sets this option, which indicates that the traffic for the primary LSP, if successfully resignaled, will be switched back to the primary ingress from the backup ingress when the primary ingress is restored.
o 还原到入口：主入口设置此选项，表示主LSP的流量如果成功重新签名，将在主入口恢复时从备份入口切换回主入口。
o P2MP Backup: This option is set to ask for the backup ingress to use backup P2MP LSP to protect the primary ingress.
o P2MP备份：此选项设置为要求备份入口使用备份P2MP LSP保护主入口。
The INGRESS_PROTECTION object may contain some subobjects of following format:
入口保护对象可能包含以下格式的一些子对象：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Reserved (zero)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents / Body of Subobject |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Reserved (zero)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents / Body of Subobject |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where Type is the type of a subobject and Length is the total size of the subobject in bytes, including Type, Length, and Contents fields.
其中，Type是子对象的类型，Length是子对象的总大小（以字节为单位），包括Type、Length和Contents字段。
When the primary ingress of a protected LSP sends a PATH message with an INGRESS_PROTECTION object to the backup ingress, the object MUST have a Backup Ingress IPv4 Address subobject containing an IPv4 address belonging to the backup ingress if IPv4 is used. The Type of the subobject is 1, and the body of the subobject is given below:
当受保护LSP的主入口向备份入口发送带有入口保护对象的路径消息时，如果使用IPv4，则该对象必须具有备份入口IPv4地址子对象，其中包含属于备份入口的IPv4地址。子对象的类型为1，子对象的主体如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Ingress IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Ingress IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Backup Ingress IPv4 Address: An IPv4 host address of backup ingress
备份入口IPv4地址：备份入口的IPv4主机地址
When the primary ingress of a protected LSP sends a PATH message with an INGRESS_PROTECTION object to the backup ingress, the object MUST have a Backup Ingress IPv6 Address subobject containing an IPv6 address belonging to the backup ingress if IPv6 is used. The Type of the subobject is 2, the body of the subobject is given below:
当受保护LSP的主入口向备份入口发送带有入口保护对象的路径消息时，如果使用IPv6，则该对象必须具有备份入口IPv6地址子对象，其中包含属于备份入口的IPv6地址。子对象的类型为2，子对象的主体如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Ingress IPv6 Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Ingress IPv6 Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Backup Ingress IPv6 Address: An IPv6 host address of backup ingress
备份入口IPv6地址：备份入口的IPv6主机地址
The INGRESS_PROTECTION object may have an Ingress IPv4 Address subobject containing an IPv4 address belonging to the primary ingress if IPv4 is used. The Type of the subobject is 3. The subobject has the following body:
如果使用IPv4，则入口保护对象可能具有入口IPv4地址子对象，其中包含属于主入口的IPv4地址。子对象的类型为3。子对象具有以下主体：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ingress IPv4 Address: An IPv4 host address of ingress
入口IPv4地址：入口的IPv4主机地址
The INGRESS_PROTECTION object may have an Ingress IPv6 Address subobject containing an IPv6 address belonging to the primary ingress if IPv6 is used. The Type of the subobject is 4. The subobject has the following body:
如果使用IPv6，则入口保护对象可能具有入口IPv6地址子对象，其中包含属于主入口的IPv6地址。子对象的类型为4。子对象具有以下主体：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress IPv6 Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress IPv6 Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ingress IPv6 Address: An IPv6 host address of ingress
入口IPv6地址：入口的IPv6主机地址
The INGRESS_PROTECTION object may have a TRAFFIC_DESCRIPTOR subobject describing the traffic to be mapped to the backup LSP on the backup ingress for locally protecting the primary ingress. The subobject types for Interface, IPv4 Prefix, IPv6 Prefix, and Application Identifier are 5, 6, 7, and 8, respectively. The subobject has the following body:
入口保护对象可以具有描述要映射到备份入口上的备份LSP的流量的流量描述符子对象，用于本地保护主入口。接口、IPv4前缀、IPv6前缀和应用程序标识符的子对象类型分别为5、6、7和8。子对象具有以下主体：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Element 1 |
~ ~
| Traffic Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Element 1 |
~ ~
| Traffic Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TRAFFIC_DESCRIPTOR subobject may contain multiple Traffic Elements of the same type as follows:
流量描述符子对象可能包含多个相同类型的流量元素，如下所示：
o Interface Traffic: Each of the Traffic Elements is a 32-bit index of an interface from which the traffic is imported into the backup LSP.
o 接口通信量：每个通信量元素都是接口的32位索引，从该接口将通信量导入备份LSP。
o IPv4 Prefix Traffic: Each of the Traffic Elements is an IPv4 prefix that contains an 8-bit prefix length followed by an IPv4 address prefix (whose length, in bits, is specified by the prefix length) that is padded to a byte boundary.
o IPv4前缀流量：每个流量元素都是IPv4前缀，包含8位前缀长度，后跟填充到字节边界的IPv4地址前缀（其长度以位为单位，由前缀长度指定）。
o IPv6 Prefix Traffic Each of the Traffic Elements is an IPv6 prefix, containing an 8-bit prefix length followed by an IPv6 address prefix (whose length, in bits, is specified by the prefix length) that is padded to a byte boundary.
o IPv6前缀流量每个流量元素都是IPv6前缀，包含8位前缀长度，后跟填充到字节边界的IPv6地址前缀（其长度以位为单位，由前缀长度指定）。
o Application Traffic: Each of the Traffic Elements is a 32-bit identifier of an application from which the traffic is imported into the backup LSP.
o 应用程序流量：每个流量元素都是将流量从中导入备份LSP的应用程序的32位标识符。
The INGRESS_PROTECTION object in a PATH message from the primary ingress to the backup ingress may have a Label-Routes subobject containing the labels and routes that the next hops of the ingress use. The Type of the subobject is 9. The subobject has the following body:
从主入口到备份入口的路径消息中的入口保护对象可以具有包含入口的下一跳使用的标签和路由的标签路由子对象。子对象的类型为9。子对象具有以下主体：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Subobjects ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Subobjects ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Subobjects in Label-Routes are copied from those in the RECORD_ROUTE objects in the RESV messages that the primary ingress receives from its next hops for the primary LSP. They MUST contain the first hops of the LSP, each of which is paired with its label.
标签路由中的子对象从主入口从其主LSP的下一个跃点接收的RESV消息中的记录路由对象中复制。它们必须包含LSP的第一个跃点，每个跃点都与其标签配对。
There are two different proposed signaling approaches to transfer the information for ingress protection. They both use the same new INGRESS_PROTECTION object. The object is sent in both PATH and RESV messages.
有两种不同的建议信令方法来传输信息以进行入口保护。它们都使用相同的新入口保护对象。对象以PATH和RESV消息的形式发送。
The primary ingress relays the information for ingress protection of an LSP to the backup ingress via PATH messages. Once the LSP is created, the ingress of the LSP sends the backup ingress a PATH message with an INGRESS_PROTECTION object with a Label-Routes subobject, which is populated with the next hops and labels. This provides sufficient information for the backup ingress to create the appropriate forwarding state and backup LSP(s).
主入口通过路径消息将LSP的入口保护信息中继到备份入口。创建LSP后，LSP入口会向备份入口发送一条路径消息，其中包含一个入口保护对象和一个标签路由子对象，该对象将填充下一个跃点和标签。这为备份入口提供了足够的信息，以创建适当的转发状态和备份LSP。
The ingress also sends the backup ingress all the other PATH messages for the LSP with an empty INGRESS_PROTECTION object. An INGRESS_PROTECTION object without any TRAFFIC_DESCRIPTOR subobject is called an empty INGRESS_PROTECTION object. Thus, the backup ingress has access to all the PATH messages needed for modification to refresh the control-plane state after a failure.
入口还向备份入口发送带有空入口保护对象的LSP的所有其他路径消息。没有任何流量描述符子对象的入口保护对象称为空入口保护对象。因此，备份入口可以访问修改所需的所有路径消息，以便在发生故障后刷新控制平面状态。
The empty INGRESS_PROTECTION object is for efficient processing of ingress protection for a P2MP LSP. A P2MP LSP's primary ingress may have more than one PATH message, each of which is sent to a next hop
空的入口保护对象用于有效处理P2MP LSP的入口保护。P2MP LSP的主入口可能有多个路径消息，每个路径消息都被发送到下一跳
along a branch of the P2MP LSP. The PATH message along a branch will be selected and sent to the backup ingress with an INGRESS_PROTECTION object containing the TRAFFIC_DESCRIPTOR subobject; all the PATH messages along the other branches will be sent to the backup ingress containing an INGRESS_PROTECTION object without any TRAFFIC_DESCRIPTOR subobject (empty INGRESS_PROTECTION object). For a P2MP LSP, the backup ingress only needs one TRAFFIC_DESCRIPTOR.
沿着P2MP LSP的分支。沿分支的路径消息将被选择并发送到具有包含流量描述符子对象的入口保护对象的备份入口；沿其他分支的所有路径消息将发送到包含入口保护对象的备份入口，而不包含任何流量描述符子对象（空入口保护对象）。对于P2MP LSP，备份入口只需要一个流量描述符。
Conceptually, a proxy ingress is created that starts the RSVP signaling. The explicit path of the LSP goes from the proxy ingress to the backup ingress and then to the real ingress. The behavior and signaling for the proxy ingress is done by the real ingress; the use of a proxy-ingress address avoids problems with loop detection. Note that the proxy ingress MUST reside within the same router as the real ingress.
从概念上讲，创建一个代理入口来启动RSVP信令。LSP的显式路径从代理入口到备份入口，然后到实际入口。代理入口的行为和信令由真实入口完成；使用代理入口地址可以避免循环检测问题。请注意，代理入口必须与实际入口位于同一路由器内。
[ Traffic Source ] *** Primary LSP
$ $ --- Backup LSP
$ $ $$ Link
$ $
[ Proxy Ingress ] [ Backup ]
[ & Ingress ] |
* |
*****[ MP ]----|
[ Traffic Source ] *** Primary LSP
$ $ --- Backup LSP
$ $ $$ Link
$ $
[ Proxy Ingress ] [ Backup ]
[ & Ingress ] |
* |
*****[ MP ]----|
Figure 2: Example of a Protected LSP with a Proxy-Ingress Node
图2：带有代理入口节点的受保护LSP示例
The backup ingress MUST know the merge points or next hops and their associated labels. This is accomplished by having the RSVP PATH and RESV messages go through the backup ingress, although the forwarding path need not go through the backup ingress. If the backup ingress fails, the ingress simply removes the INGRESS_PROTECTION object and forwards the PATH messages to the LSP's next hop(s). If the ingress has its LSP configured for ingress protection, then the ingress can add the backup ingress and itself to the Explicit Route Object (ERO) and start forwarding the PATH messages to the backup ingress.
备份入口必须知道合并点或下一个跃点及其相关标签。这是通过让RSVP路径和RESV消息通过备份入口来实现的，尽管转发路径不需要通过备份入口。如果备份入口失败，入口将删除入口保护对象，并将路径消息转发到LSP的下一跳。如果入口将其LSP配置为入口保护，则入口可以将备份入口及其自身添加到显式路由对象（ERO），并开始将路径消息转发到备份入口。
Slightly different behavior can apply for the on-path and off-path cases. In the on-path case, the backup ingress is a next-hop node after the ingress for the LSP. In the off-path case, the backup ingress is not any next-hop node after the ingress for all associated sub-LSPs.
稍微不同的行为可以应用于路径上和路径外的情况。在路径上的情况下，备份入口是LSP入口之后的下一跳节点。在非路径情况下，备份入口不是所有关联子LSP入口之后的任何下一跳节点。
The key advantage of this approach is that it minimizes the special handling code required. Because the backup ingress is on the signaling path, it can receive various notifications. It easily has
这种方法的主要优点是它最小化了所需的特殊处理代码。因为备份入口位于信令路径上，所以它可以接收各种通知。它很容易做到
access to all the PATH messages needed for a modification to be sent to refresh the control-plane state after a failure.
访问故障后发送修改以刷新控制平面状态所需的所有路径消息。
The primary ingress MUST be configured with a couple of pieces of information for ingress protection.
主入口必须配置两条入口保护信息。
o Backup Ingress Address: The primary ingress MUST know the IP address of the backup ingress it wants to be used before it can use the INGRESS_PROTECTION object.
o 备份入口地址：主入口必须知道它想要使用的备份入口的IP地址，然后才能使用入口保护对象。
o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The Proxy-Ingress-Id is only used in the RECORD_ROUTE object for recording the proxy ingress. If no Proxy-Ingress-Id is specified, then a local interface address that will not otherwise be included in the RECORD_ROUTE object can be used. A similar technique is used in Section 6.1.1. of [RFC4090].
o 代理入口Id（仅适用于代理入口方法）：代理入口Id仅在记录路由对象中用于记录代理入口。如果未指定代理入口Id，则可以使用记录路由对象中不包含的本地接口地址。第6.1.1节中使用了类似的技术。属于[RFC4090]。
o Application Traffic Identifier: The primary ingress and backup ingress MUST both know what application traffic should be directed into the LSP. If a list of prefixes in the TRAFFIC_DESCRIPTOR subobject will not suffice, then a commonly understood Application Traffic Identifier can be sent between the primary ingress and backup ingress. The exact meaning of the identifier should be configured similarly at both the primary ingress and backup ingress. The Application Traffic Identifier is understood within the unique context of the primary ingress and backup ingress.
o 应用程序流量标识符：主入口和备份入口必须都知道应该将哪些应用程序流量定向到LSP。如果流量描述符子对象中的前缀列表不够，则可以在主入口和备份入口之间发送通常理解的应用程序流量标识符。标识符的确切含义应在主入口和备份入口进行类似配置。在主入口和备份入口的唯一上下文中理解应用程序通信量标识符。
o A Connection between Backup Ingress and Primary Ingress: If there is not any direct link between the primary ingress and the backup ingress, a tunnel MUST be configured between them.
o 备份入口和主入口之间的连接：如果主入口和备份入口之间没有任何直接链路，则必须在它们之间配置隧道。
With this additional information, the primary ingress can create and signal the necessary RSVP extensions to support ingress protection.
有了这些附加信息，主入口可以创建必要的RSVP扩展并发出信号，以支持入口保护。
To protect the primary ingress of an LSP, the primary ingress MUST do the following after the LSP is up.
为了保护LSP的主入口，主入口必须在LSP启动后执行以下操作。
1. Select a PATH message P0 for the LSP.
1. 为LSP选择路径消息P0。
2. If the backup ingress is off path (the backup ingress is not the next hop of the primary ingress for P0), then send it a PATH message P0' with the content from P0 and an INGRESS_PROTECTION object; else (the backup ingress is a next hop, i.e., on-path case) add an INGRESS_PROTECTION object into the existing PATH
2. 如果备份入口是非路径的（备份入口不是P0主入口的下一个跃点），则向其发送路径消息P0'，其中包含来自P0的内容和入口保护对象；否则（备份入口是下一跳，即在路径情况下）将入口保护对象添加到现有路径中
message to the backup ingress (i.e., the next hop). The object contains the TRAFFIC_DESCRIPTOR subobject, the Backup Ingress Address subobject and the Label-Routes subobject. The options field is set to indicate whether a backup P2MP LSP is desired. The Label-Routes subobject contains the next hops of the primary ingress and their labels. Note that for the on-path case, there is an existing PATH message to the backup ingress (i.e., the next hop), and we just add an INGRESS_PROTECTION object into the existing PATH message to be sent to the backup ingress. We do not send a separate PATH message to the backup ingress for this existing PATH message.
发送到备份入口（即下一跳）的消息。该对象包含流量描述符子对象、备份入口地址子对象和标签路由子对象。选项字段设置为指示是否需要备份P2MP LSP。标签路由子对象包含主入口的下一个跃点及其标签。请注意，对于在路径上的情况，存在到备份入口（即下一跳）的现有路径消息，我们只需将入口保护对象添加到现有路径消息中，以发送到备份入口。对于此现有路径消息，我们不会向备份入口发送单独的路径消息。
3. For each Pi of the other PATH messages for the LSP, send the backup ingress a PATH message Pi' with the content copied from Pi and an empty INGRESS_PROTECTION object.
3. 对于LSP的其他路径消息中的每个Pi，向备份入口发送一条路径消息Pi'，其中包含从Pi复制的内容和一个空的入口保护对象。
For every PATH message Pj' (i.e., P0'/Pi') to be sent to the backup ingress, it has the same SESSION as Pj (i.e., P0/Pi). If the backup ingress is off path, the primary ingress updates Pj' according to the backup ingress as its next hop before sending it. It adds the backup ingress to the beginning of the ERO and sets RSVP_HOP based on the interface to the backup ingress. The primary ingress MUST NOT set up any forwarding state to the backup ingress if the backup ingress is off path.
对于要发送到备份入口的每个路径消息Pj'（即P0'/Pi'），其会话与Pj（即P0/Pi）相同。如果备份入口是非路径的，则主入口在发送前根据备份入口作为其下一跳更新Pj’。它将备份入口添加到ERO的开头，并根据备份入口的接口设置RSVP_跃点。如果备份入口不在路径范围内，则主入口不得向备份入口设置任何转发状态。
The primary ingress is responsible for starting the RSVP signaling for the proxy-ingress node. To do this, the following MUST be done for the RSVP PATH message.
主入口负责启动代理入口节点的RSVP信令。为此，必须对RSVP PATH消息执行以下操作。
1. Compute the EROs for the LSP as normal for the ingress.
1. 将LSP的ERO计算为入口的正常值。
2. If the selected backup ingress node is not the first node on the path (for all sub-LSPs), then insert it at the beginning of the ERO first, then the backup ingress node, and then the ingress node.
2. 如果选定的备份入口节点不是路径上的第一个节点（对于所有子LSP），则首先将其插入ERO的开头，然后插入备份入口节点，然后插入入口节点。
3. In the PATH RECORD_ROUTE Object (RRO), instead of recording the ingress node's address, replace it with the Proxy-Ingress-Id.
3. 在路径记录_路由对象（RRO）中，不记录入口节点的地址，而是将其替换为Proxy-ingres-Id。
4. Leave the hop (HOP) object populated as usual with information for the ingress node.
4. 让跳跃（hop）对象像往常一样填充入口节点的信息。
5. Add the INGRESS_PROTECTION object to the PATH message. Include the Backup Ingress Address (IPv4 or IPv6) subobject and the TRAFFIC_DESCRIPTOR subobject. Set or clear the options indicating that a backup P2MP LSP is desired.
5. 将入口保护对象添加到路径消息。包括备份入口地址（IPv4或IPv6）子对象和流量描述符子对象。设置或清除指示需要备份P2MP LSP的选项。
6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path message. Indicate whether one-to-one backup is desired. Indicate whether facility backup is desired.
6. 或者，将快速重路由对象[RFC4090]添加到路径消息。指示是否需要一对一备份。指示是否需要设施备份。
7. The RSVP PATH message is sent to the backup node as normal.
7. RSVP PATH消息将正常发送到备份节点。
If the ingress detects that it can't communicate with the backup ingress, then the ingress SHOULD instead send the PATH message to the next hop indicated in the ERO computed in step 1. Once the ingress detects that it can communicate with the backup ingress, the ingress SHOULD follow steps 1-7 to obtain ingress failure protection.
如果入口检测到它无法与备份入口通信，则入口应改为向步骤1中计算的ERO中指示的下一跳发送路径消息。一旦入口检测到它可以与备份入口通信，入口应遵循步骤1-7以获得入口故障保护。
When the ingress node receives an RSVP PATH message with an INGRESS_PROTECTION object and the object specifies that node as the ingress node and the Previous Hop (PHOP) as the backup ingress node, the ingress node SHOULD remove the INGRESS_PROTECTION object from the PATH message before sending it out. Additionally, the ingress node MUST store that it will install ingress forwarding state for the LSP rather than midpoint forwarding.
当入口节点接收到带有入口保护对象的RSVP PATH消息，并且该对象将该节点指定为入口节点，并将上一跳（PHOP）指定为备份入口节点时，入口节点应在将其发送出去之前从路径消息中移除入口保护对象。此外，入口节点必须存储它将为LSP安装入口转发状态，而不是中点转发。
When an RSVP RESV message is received by the ingress, it uses the Next Hop (NHOP) to determine whether the message is received from the backup ingress or from a different node. The stored associated PATH message contains an INGRESS_PROTECTION object that identifies the backup ingress node. If the RESV message is not from the backup node, then the ingress forwarding state SHOULD be set up, and the INGRESS_PROTECTION object MUST be added to the RESV before it is sent to the NHOP, which SHOULD be the backup node. If the RESV message is from the backup node, then the LSP SHOULD be considered available for use.
当入口接收到RSVP RESV消息时，它使用下一跳（NHOP）来确定该消息是从备份入口接收还是从不同节点接收。存储的关联路径消息包含标识备份入口节点的入口保护对象。如果RESV消息不是来自备份节点，则应设置入口转发状态，并且必须将入口保护对象添加到RESV，然后再将其发送到NHOP（应为备份节点）。如果RESV消息来自备份节点，则应认为LSP可供使用。
If the backup ingress node is on the forwarding path, then a RESV is received with an INGRESS_PROTECTION object and an NHOP that matches the backup ingress. In this case, the ingress node's address will not appear after the backup ingress in the RRO. The ingress node SHOULD set up the ingress forwarding state, just as is done if the ingress node of the LSP weren't protected.
如果备份入口节点位于转发路径上，则接收到带有入口保护对象和与备份入口匹配的NHOP的RESV。在这种情况下，入口节点的地址将不会出现在RRO中的备份入口之后。入口节点应设置入口转发状态，就像LSP的入口节点未受保护一样。
A Label Edge Router (LER) determines that the ingress local protection is requested for an LSP if the INGRESS_PROTECTION object is included in the PATH message it receives for the LSP. The LER can further determine that it is the backup ingress if one of its addresses is in the Backup Ingress Address subobject of the INGRESS_PROTECTION object. The LER as the backup ingress will assume full responsibility of the ingress after the primary ingress fails. In addition, the LER determines that it is off path if it is not any
如果入口保护对象包含在为LSP接收的路径消息中，则标签边缘路由器（LER）确定为LSP请求入口本地保护。如果LER的一个地址位于入口保护对象的备份入口地址子对象中，则LER可以进一步确定它是备份入口。主入口故障后，作为备用入口的LER将承担入口的全部责任。此外，如果不存在路径，LER将确定该路径偏离路径
node of the LSP. The LER determines whether it uses the Relay-Message Method or the Proxy-Ingress Method according to configurations.
LSP的节点。LER根据配置确定是使用中继消息方法还是代理入口方法。
The backup ingress considers itself a Point of Local Repair (PLR) and the primary ingress its next hop, and it provides a local protection for the primary ingress. It behaves very similarly to a PLR providing fast reroute where the primary ingress is considered to be the failure point to protect. Where not otherwise specified, the behavior given in [RFC4090] for a PLR applies.
备份入口将自己视为本地修复点（PLR），主入口将作为下一跳，并为主入口提供本地保护。它的行为非常类似于提供快速重路由的PLR，其中主入口被认为是要保护的故障点。除非另有规定，否则[RFC4090]中给出的PLR行为适用。
The backup ingress MUST follow the control options specified in the INGRESS_PROTECTION object and the flags and specifications in the FAST-REROUTE object. This applies to providing a P2MP backup if the "P2MP backup" is set, a one-to-one backup if "one-to-one desired" is set, a facility backup if the "facility backup desired" is set, and backup paths that support both the desired bandwidth and administrative groups that are requested.
备份入口必须遵循入口保护对象中指定的控制选项以及快速重路由对象中的标志和规范。这适用于在设置了“P2MP备份”的情况下提供P2MP备份，在设置了“所需一对一”的情况下提供一对一备份，在设置了“所需设施备份”的情况下提供设施备份，以及支持所请求的所需带宽和管理组的备份路径。
If multiple non-empty INGRESS_PROTECTION objects have been received via multiple PATH messages for the same LSP, then the most recent one MUST be the one used.
如果已通过同一LSP的多条路径消息接收到多个非空入口保护对象，则必须使用最近的一个。
The backup ingress creates the appropriate forwarding state for the backup LSP tunnel(s) to the merge point(s).
备份入口为备份LSP隧道创建到合并点的适当转发状态。
When the backup ingress sends a RESV message to the primary ingress, it MUST add an INGRESS_PROTECTION object into the message. It MUST set or clear the flags in the object to report "Ingress local protection available", "Ingress local protection in use", and "bandwidth protection".
当备份入口向主入口发送RESV消息时，它必须在消息中添加入口保护对象。它必须设置或清除对象中的标志，以报告“入口本地保护可用”、“入口本地保护正在使用”和“带宽保护”。
If the backup ingress doesn't have a backup LSP tunnel to each of the merge points, it SHOULD clear "Ingress local protection available" and set NUB to the number of the merge points to which there is no backup LSP.
如果备份入口没有到每个合并点的备份LSP通道，则应清除“入口本地保护可用”，并将NUB设置为没有备份LSP的合并点的数量。
When the primary ingress fails, the backup ingress redirects the traffic from a source into the backup P2P LSPs or the backup P2MP LSP transmitting the traffic to the next hops of the primary ingress, where the traffic is merged into the protected LSP.
当主入口失败时，备份入口将流量从源重定向到备份P2P LSP或备份P2MP LSP，将流量传输到主入口的下一个跃点，其中流量合并到受保护的LSP中。
In this case, the backup ingress MUST keep the PATH message with the INGRESS_PROTECTION object received from the primary ingress and the RESV message with the INGRESS_PROTECTION object to be sent to the primary ingress. The backup ingress MUST set the "local protection
在这种情况下，备份入口必须保留从主入口接收的带有入口保护对象的PATH消息和要发送到主入口的带有入口保护对象的RESV消息。备份入口必须设置“本地保护”
in use" flag in the RESV message, which indicates that the backup ingress is actively redirecting the traffic into the backup P2P LSPs or the backup P2MP LSP for locally protecting the primary ingress failure.
RESV消息中的“正在使用”标志，表示备份入口正在主动将流量重定向到备份P2P LSP或备份P2MP LSP，以本地保护主入口故障。
Note that the RESV message with this piece of information will not be sent to the primary ingress because the primary ingress has failed.
请注意，带有此信息的RESV消息将不会发送到主入口，因为主入口已失败。
If the backup ingress has not received any PATH messages from the primary ingress for an extended period of time (e.g., a cleanup timeout interval) and a confirmed primary ingress failure did not occur, then the standard RSVP soft-state removal SHOULD occur. The backup ingress SHALL remove the state for the PATH message from the primary ingress and either tear down the one-to-one backup LSPs for protecting the primary ingress if one-to-one backup is used or unbind the facility backup LSPs if facility backup is used.
如果备份入口在很长一段时间内（例如，清理超时时间间隔）未收到来自主入口的任何路径消息，并且未发生确认的主入口故障，则应进行标准RSVP软状态删除。备份入口应从主入口移除路径消息的状态，如果使用一对一备份，则拆除一对一备份LSP以保护主入口；如果使用设施备份，则解除设施备份LSP的绑定。
When the backup ingress receives a PATH message from the primary ingress for locally protecting the primary ingress of a protected LSP, it MUST check to see if any critical information has been changed. If the next hops of the primary ingress are changed, the backup ingress SHALL update its backup LSP(s) accordingly.
当备份入口从主入口接收到用于本地保护受保护LSP的主入口的PATH消息时，它必须检查是否有任何关键信息已更改。如果主入口的下一个跃点发生变化，则备份入口应相应地更新其备份LSP。
When the backup ingress receives a PATH message with a non-empty INGRESS_PROTECTION object, it examines the object to learn what traffic associated with the LSP. It determines the next hops to be merged to by examining the Label-Routes subobject in the object.
当备份入口接收到带有非空入口保护对象的PATH消息时，它会检查该对象以了解与LSP关联的通信量。它通过检查对象中的标签路由子对象来确定要合并到的下一个跃点。
The backup ingress MUST store the PATH message received from the primary ingress but NOT forward it.
备份入口必须存储从主入口接收的路径消息，但不能转发它。
The backup ingress responds with a RESV message to the PATH message received from the primary ingress. If the backup ingress is off path, the LABEL object in the RESV message contains IMPLICIT-NULL. If the INGRESS_PROTECTION object is not "empty", the backup ingress SHALL send the RESV message with the state indicating protection is available after the backup LSP(s) are successfully established.
备份入口以RESV消息响应从主入口接收到的PATH消息。如果备份入口为非路径，则RESV消息中的标签对象包含IMPLICIT-NULL。如果入口保护对象不是“空”的，则备份入口应发送RESV消息，其状态指示在成功建立备份LSP后保护可用。
When receiving a RESV message for an LSP from a router that is not primary ingress, the backup ingress collects the pair of (IPv4/IPv6 subobject, Label subobject) in the second place to the top pair in the RECORD_ROUTE object of the message. It determines the next hops to be merged according to the set of the pairs collected. If a Label-Routes subobject is included in the INGRESS_PROTECTION object,
当从非主入口的路由器接收LSP的RESV消息时，备份入口收集消息记录路由对象中第二位的对（IPv4/IPv6子对象，标签子对象）。它根据收集到的对集确定要合并的下一个跃点。如果入口保护对象中包含标签路由子对象，
the included IPv4/IPv6 subobjects are used to filter the set down to the specific next hops where protection is desired. An RESV message MUST have been received before the backup ingress can create or select the appropriate backup LSP.
包含的IPv4/IPv6子对象用于将设置过滤到需要保护的特定下一跳。在备份入口可以创建或选择适当的备份LSP之前，必须已收到RESV消息。
When the backup ingress receives a PATH message with the INGRESS_PROTECTION object, the backup ingress examines the object to learn what traffic associated with the LSP. The backup ingress forwards the PATH message to the ingress node with the normal RSVP changes.
当备份入口接收到带有入口保护对象的PATH消息时，备份入口检查该对象以了解与LSP相关联的通信量。备份入口在正常RSVP更改的情况下将路径消息转发到入口节点。
When the backup ingress receives a RESV message with the INGRESS_PROTECTION object, the backup ingress records an IMPLICIT-NULL label in the RRO. Then, the backup ingress forwards the RESV message to the ingress node, which is acting for the proxy ingress.
当备份入口接收到带有入口保护对象的RESV消息时，备份入口在RRO中记录一个隐式空标签。然后，备份入口将RESV消息转发给入口节点，该节点代表代理入口。
An LER as the backup ingress determines that it is on path if one of its addresses is a next hop of the primary ingress; for the Proxy-Ingress Method, the primary ingress is determined as not its next hop by checking the PATH message with the INGRESS_PROTECTION object received from the primary ingress. The LER on path MUST send the corresponding PATH messages without any INGRESS_PROTECTION object to its next hops. It creates a number of backup P2P LSPs or a backup P2MP LSP from itself to the other next hops (i.e., the next hops other than the backup ingress) of the primary ingress. The other next hops are from the Label-Routes subobject.
如果其地址之一是主入口的下一跳，则作为备份入口的LER确定其在路径上；对于代理入口方法，通过使用从主入口接收的入口保护对象检查路径消息，确定主入口不是其下一跳。路径上的LER必须在没有任何入口保护对象的情况下向其下一个跃点发送相应的路径消息。它从自身到主入口的其他下一跳（即，备份入口以外的下一跳）创建多个备份P2P LSP或备份P2MP LSP。其他下一个跃点来自“标签路由”子对象。
It also creates a forwarding entry, which sends/multicasts the traffic from the source to the next hops of the backup ingress along the protected LSP when the primary ingress fails. The traffic is described by the TRAFFIC_DESCRIPTOR.
它还创建一个转发条目，当主入口出现故障时，该条目将流量从源发送/多播到受保护的LSP上的备份入口的下一个跃点。流量由流量描述符描述。
After setting up all the backup P2P LSPs or the backup P2MP LSP, the backup ingress creates forwarding entry(s) for importing the traffic into the backup LSP(s) from the source when the primary ingress fails. Then, it MUST send the primary ingress a RESV message with an INGRESS_PROTECTION object. The object contains the state of the local protection, such as having the "local protection available" flag set to one, which indicates that the primary ingress is locally protected.
设置所有备份P2P LSP或备份P2MP LSP后，备份入口将创建转发条目，以便在主入口失败时将流量从源导入备份LSP。然后，它必须向主入口发送带有入口保护对象的RESV消息。对象包含本地保护的状态，例如将“local protection available”（本地保护可用）标志设置为1，这表示主入口受到本地保护。
When the primary ingress fails, the backup ingress sends/multicasts the traffic from the source to its next hops along the protected LSP and imports the traffic into each of the backup P2P LSPs or to the
当主入口失败时，备份入口将流量从源发送/多播到其沿受保护的LSP的下一个跃点，并将流量导入每个备份P2P LSP或服务器
backup P2MP LSP transmitting the traffic to the other next hops of the primary ingress, where the traffic is merged into a protected LSP.
备份P2MP LSP，将流量传输到主入口的其他下一个跃点，在此，流量合并到受保护的LSP中。
During the local repair, the backup ingress MUST continue to send the PATH messages to its next hops as before and keep the PATH message with the INGRESS_PROTECTION object received from the primary ingress and the RESV message with the INGRESS_PROTECTION object to be sent to the primary ingress. It MUST set the "local protection in use" flag in the RESV message.
在本地修复期间，备份入口必须像以前一样继续向其下一个跃点发送路径消息，并保留从主入口接收的带有入口保护对象的路径消息和要发送到主入口的带有入口保护对象的RESV消息。它必须在RESV消息中设置“本地保护正在使用”标志。
As described in [RFC4090], it is necessary to refresh the PATH messages via the backup LSP(s). The backup ingress MUST wait to refresh the PATH messages until it can accurately detect that the ingress node has failed. An example of such an accurate detection would be that the IGP has no bidirectional links to the ingress node, or a BFD session to the primary ingress' loopback address has failed and stayed failed after the network has reconverged.
如[RFC4090]所述，有必要通过备份LSP刷新路径消息。备份入口必须等待刷新路径消息，直到能够准确检测到入口节点发生故障。这种准确检测的一个例子是IGP没有到入口节点的双向链路，或者到主入口的环回地址的BFD会话已经失败，并且在网络重新聚合之后仍然失败。
As described in Section 6.4.3 of [RFC4090], the backup ingress, acting as PLR, MUST modify and send any saved PATH messages associated with the primary LSP to the corresponding next hops through backup LSP(s). Any PATH message sent will not contain any INGRESS_PROTECTION objects. The RSVP_HOP object in the message contains an IP source address belonging to the backup ingress. The SENDER_TEMPLATE object has the Backup Ingress Address as its tunnel sender address.
如[RFC4090]第6.4.3节所述，作为PLR的备份入口必须修改与主LSP相关的任何保存路径消息，并通过备份LSP将其发送到相应的下一个跃点。发送的任何路径消息将不包含任何入口保护对象。消息中的RSVP_HOP对象包含属于备份入口的IP源地址。发送方\模板对象将备份入口地址作为其隧道发送方地址。
Upon a failure event in the (primary) ingress of a protected LSP, the protected LSP is locally repaired by the backup ingress. There are a couple of basic strategies for restoring the LSP to a full working path.
当受保护LSP的（主）入口发生故障事件时，受保护LSP将由备份入口进行本地修复。将LSP恢复到完整工作路径有两种基本策略。
o Revert to Primary Ingress: When the primary ingress is restored, it resignals each of the LSPs that start from the primary ingress. The traffic for every LSP successfully resignaled is switched back to the primary ingress from the backup ingress.
o 还原到主入口：当主入口恢复时，它会重新签名从主入口开始的每个LSP。成功重新签名的每个LSP的流量都从备份入口切换回主入口。
o Global Repair by Backup Ingress: After determining that the primary ingress of an LSP has failed, the backup ingress computes a new optimal path, signals a new LSP along the new path, and switches the traffic to the new LSP.
o 通过备份入口进行全局修复：在确定LSP的主入口失败后，备份入口计算新的最佳路径，沿新路径向新LSP发送信号，并将流量切换到新LSP。
If "Revert to Primary Ingress" is desired for a protected LSP, the (primary) ingress of the LSP SHOULD resignal the LSP that starts from the primary ingress after the primary ingress restores. After the LSP is resignaled successfully, the traffic SHOULD be switched back to the primary ingress from the backup ingress on the source node and redirected into the LSP starting from the primary ingress.
如果受保护的LSP需要“恢复为主入口”，则LSP的（主）入口应在主入口恢复后重新标记从主入口开始的LSP。LSP成功重签名后，流量应从源节点上的备份入口切换回主入口，并从主入口开始重定向到LSP。
The primary ingress can specify the "Revert to Ingress" control option in the INGRESS_PROTECTION object in the PATH messages to the backup ingress. After receiving the "Revert to Ingress" control option, the backup ingress MUST stop sending/refreshing PATH messages for the protected LSP.
主入口可以在备份入口的路径消息中的入口保护对象中指定“恢复到入口”控制选项。在收到“恢复到入口”控制选项后，备份入口必须停止发送/刷新受保护LSP的路径消息。
When the backup ingress has determined that the primary ingress of the protected LSP has failed (e.g., via the IGP), it can compute a new path and signal a new LSP along the new path so that it no longer relies upon local repair. To do this, the backup ingress MUST use the same tunnel sender address in the SENDER_TEMPLATE object and allocate an LSP ID different from the one of the old LSP as the LSP ID of the new LSP. This allows the new LSP to share resources with the old LSP. Alternately, the backup ingress can create a new LSP with no bandwidth reservation that duplicates the path(s) of the protected LSP, move traffic to the new LSP, delete the protected LSP, and then resignal the new LSP with bandwidth.
当备份入口确定受保护LSP的主入口发生故障（例如，通过IGP）时，它可以计算新路径并沿新路径发送新LSP信号，以便不再依赖本地修复。为此，备份入口必须在sender_TEMPLATE对象中使用相同的隧道发送方地址，并分配一个不同于旧LSP的LSP ID作为新LSP的LSP ID。这允许新LSP与旧LSP共享资源。或者，备份入口可以创建一个没有带宽保留的新LSP，该LSP复制受保护LSP的路径，将流量移动到新LSP，删除受保护LSP，然后使用带宽重新指定新LSP。
In principle, this document does not introduce new security issues. The security considerations pertaining to [RFC4090], [RFC4875], [RFC2205], and [RFC3209] remain relevant.
原则上，本文件不会引入新的安全问题。与[RFC4090]、[RFC4875]、[RFC2205]和[RFC3209]相关的安全注意事项仍然相关。
This extension reuses and extends semantics and procedures defined in [RFC2205], [RFC3209], [RFC4090], and [RFC4875] to support ingress protection. The new object defined to indicate ingress protection has a Class Number of the form 0bbbbbbb. Per [RFC2205], a node not supporting this extension will not recognize the new Class Number and should respond with an "Unknown Object Class" error. The error message will propagate to the ingress, which can then take action to avoid the incompatible node as a backup ingress or may simply terminate the session.
此扩展重用并扩展[RFC2205]、[RFC3209]、[RFC4090]和[RFC4875]中定义的语义和过程，以支持入口保护。定义用于指示入口保护的新对象的类号为0BBB。根据[RFC2205]，不支持此扩展的节点将无法识别新的类号，并应以“未知对象类”错误进行响应。错误消息将传播到入口，入口可以采取措施避免不兼容节点作为备份入口，或者可以简单地终止会话。
This document has no IANA actions.
本文档没有IANA操作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源保留协议（RSVP）——版本1功能规范”，RFC 2205，DOI 10.17487/RFC2205，1997年9月<https://www.rfc-editor.org/info/rfc2205>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, DOI 10.17487/RFC3936, October 2004, <https://www.rfc-editor.org/info/rfc3936>.
[RFC3936]Kompella，K.和J.Lang，“修改资源预留协议（RSVP）的程序”，BCP 96，RFC 3936，DOI 10.17487/RFC3936，2004年10月<https://www.rfc-editor.org/info/rfc3936>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE的快速重路由扩展”，RFC 4090，DOI 10.17487/RFC4090，2005年5月<https://www.rfc-editor.org/info/rfc4090>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，DOI 10.17487/RFC4875，2007年5月<https://www.rfc-editor.org/info/rfc4875>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011, <https://www.rfc-editor.org/info/rfc6378>.
[RFC6378]Y.Weingarten，Ed.，Bryant，S.，Osborne，E.，Sprecher，N.，和A.Fulignoli，Ed.，“MPLS传输模式（MPLS-TP）线性保护”，RFC 6378，DOI 10.17487/RFC6378，2011年10月<https://www.rfc-editor.org/info/rfc6378>.
Acknowledgements
致谢
The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, Alia Atlas, Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, Gregory Mirsky, and Ronhazli Adam for their valuable comments and suggestions on this document.
作者要感谢Nobo Akiya、Rahul Aggarwal、Eric Osborne、Ross Callon、Loa Andersson、Daniel King、Michael Yue、Alia Atlas、Olufemi Komolafe、Rob Rennison、Neil Harrison、Kannan Sampath、Gregory Mirsky和Ronhazli Adam对本文件提出的宝贵意见和建议。
Contributors
贡献者
The following people contributed significantly to the content of this document and should be considered coauthors:
以下人员对本文件的内容做出了重大贡献，应被视为共同作者：
Autumn Liu Ciena United States of America Email: hliu@ciena.com
秋天：美国电子邮件：hliu@ciena.com
Zhenbin Li Huawei Technologies Email: zhenbin.li@huawei.com
李振斌华为技术电子邮件：振斌。li@huawei.com
Yimin Shen Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America Email: yshen@juniper.net
美国马萨诸塞州韦斯特福德科技园大道10号伊敏·沈·杜松网络美国邮箱：01886yshen@juniper.net
Tarek Saad Cisco Systems Email: tsaad@cisco.com
Tarek Saad Cisco Systems电子邮件：tsaad@cisco.com
Fengman Xu Verizon 2400 N. Glenville Dr Richardson, TX 75082 United States of America Email: fengman.xu@verizon.com
Fengman Xu Verizon 2400 N.Glenville Richardson博士，德克萨斯州75082美利坚合众国电子邮件：Fengman。xu@verizon.com
The following people also contributed to the content of this document:
以下人员也参与了本文件的内容：
Ning So Tata Communications 2613 Fairbourne Cir. Plano, TX 75082 United States of America Email: ningso01@gmail.com
宁苏塔塔通信公司美国德克萨斯州普莱诺费尔伯恩巡回法庭2613邮编75082电子邮件：ningso01@gmail.com
Mehmet Toy Verizon United States of America Email: mehmet.toy@verizon.com
Mehmet Toy Verizon美利坚合众国电子邮件：Mehmet。toy@verizon.com
Lei Liu United States of America Email: liulei.kddi@gmail.com
刘磊美利坚合众国电子邮件：刘磊。kddi@gmail.com
Renwei Li Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 United States of America Email: renwei.li@huawei.com
美国加利福尼亚州圣克拉拉市中央高速公路2330号华为技术公司，邮编95050电子邮件：Renwei。li@huawei.com
Quintin Zhao Huawei Technologies Boston, MA United States of America Email: quintin.zhao@huawei.com
Quintin Zhao Huawei Technologies马萨诸塞州波士顿电子邮件：Quintin。zhao@huawei.com
Boris Zhang Telus Communications 200 Consilium Pl Floor 15 Toronto, ON M1H 3J3 Canada Email: Boris.Zhang@telus.com
Boris Zhang Telus Communications 200 Consilium Pl Floor 15多伦多M1H 3J3加拿大电子邮件：Boris。Zhang@telus.com
Markus Jork Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America Email: mjork@juniper.net
马萨诸塞州韦斯特福德科技园大道10号Markus Jork Juniper Networks美国邮箱：01886mjork@juniper.net
Authors' Addresses
作者地址
Huaimo Chen (editor) Huawei Technologies Boston, MA United States of America
陈怀默（编辑）美国马萨诸塞州波士顿华为技术有限公司
Email: huaimo.chen@huawei.com
Email: huaimo.chen@huawei.com
Raveendra Torvi (editor) Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Ravendra Torvi（编辑）Juniper Networks美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: rtorvi@juniper.net
Email: rtorvi@juniper.net