Network Working Group Y. Ohba
Request for Comments: 3063 Y. Katsube
Category: Experimental Toshiba
E. Rosen
Cisco Systems
P. Doolan
Ennovate Networks
February 2001
Network Working Group Y. Ohba
Request for Comments: 3063 Y. Katsube
Category: Experimental Toshiba
E. Rosen
Cisco Systems
P. Doolan
Ennovate Networks
February 2001
MPLS Loop Prevention Mechanism
MPLS环路预防机制
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. The mechanism is compatible with, but does not require, VC merge. The mechanism can be used with either the ordered downstream-on-demand allocation or ordered downstream allocation. The amount of information that must be passed in a protocol message is tightly bounded (i.e., no path-vector is used). When a node needs to change its next hop, a distributed procedure is executed, but only nodes which are downstream of the change are involved.
本文提出了一种基于“线程”的简单机制，用于防止多协议标签交换（MPLS）建立具有循环的标签交换路径（LSP）。该机制与VC merge兼容，但不需要。该机制可用于按需有序下游分配或有序下游分配。协议消息中必须传递的信息量是有严格限制的（即不使用路径向量）。当一个节点需要更改其下一跳时，将执行一个分布式过程，但只涉及更改下游的节点。
Table of Contents
目录
1 Introduction .......................................... 2
2 Basic definitions ..................................... 3
3 Thread basics ......................................... 5
3.1 Thread attributes ..................................... 5
3.2 Thread loop ........................................... 7
3.3 Primitive thread actions .............................. 7
3.4 Examples of primitive thread actions ................. 10
4 Thread algorithm ...................................... 14
5 Applicability of the algorithm ........................ 14
5.1 LSP Loop prevention/detection ......................... 15
5.2 Using old path while looping on new path .............. 15
5.3 How to deal with ordered downstream allocation ........ 15
5.4 How to realize load splitting ......................... 15
6 Why this works ........................................ 16
6.1 Why a thread with unknown hop count is extended ....... 16
6.2 Why a rewound thread cannot contain a loop ............ 17
6.2.1 Case1: LSP with known link hop counts ................. 17
6.2.1 Case2: LSP with unknown link hop counts ............... 17
6.3 Why L3 loop is detected ............................... 17
6.4 Why L3 loop is not mis-detected ....................... 17
6.5 How a stalled thread automatically recovers from loop . 18
6.6 Why different colored threads do not chase each other . 18
7 Loop prevention examples .............................. 19
7.1 First example ......................................... 19
7.2 Second example ........................................ 23
8 Thread control block .................................. 24
8.1 Finite state machine .................................. 25
9 Comparison with path-vector/diffusion method .......... 28
10 Security Considerations ............................... 29
11 Intellectual Property Considerations .................. 29
12 Acknowledgments ....................................... 29
13 Authors' Addresses .................................... 30
14 References ............................................ 30
Appendix A Further discussion of the algorithm ............. 31
Full Copyright Statement ..................................... 44
1 Introduction .......................................... 2
2 Basic definitions ..................................... 3
3 Thread basics ......................................... 5
3.1 Thread attributes ..................................... 5
3.2 Thread loop ........................................... 7
3.3 Primitive thread actions .............................. 7
3.4 Examples of primitive thread actions ................. 10
4 Thread algorithm ...................................... 14
5 Applicability of the algorithm ........................ 14
5.1 LSP Loop prevention/detection ......................... 15
5.2 Using old path while looping on new path .............. 15
5.3 How to deal with ordered downstream allocation ........ 15
5.4 How to realize load splitting ......................... 15
6 Why this works ........................................ 16
6.1 Why a thread with unknown hop count is extended ....... 16
6.2 Why a rewound thread cannot contain a loop ............ 17
6.2.1 Case1: LSP with known link hop counts ................. 17
6.2.1 Case2: LSP with unknown link hop counts ............... 17
6.3 Why L3 loop is detected ............................... 17
6.4 Why L3 loop is not mis-detected ....................... 17
6.5 How a stalled thread automatically recovers from loop . 18
6.6 Why different colored threads do not chase each other . 18
7 Loop prevention examples .............................. 19
7.1 First example ......................................... 19
7.2 Second example ........................................ 23
8 Thread control block .................................. 24
8.1 Finite state machine .................................. 25
9 Comparison with path-vector/diffusion method .......... 28
10 Security Considerations ............................... 29
11 Intellectual Property Considerations .................. 29
12 Acknowledgments ....................................... 29
13 Authors' Addresses .................................... 30
14 References ............................................ 30
Appendix A Further discussion of the algorithm ............. 31
Full Copyright Statement ..................................... 44
This paper presents a simple mechanism, based on "threads", which can be used to prevent MPLS from setting up label switched paths (LSPs) which have loops.
本文提出了一种基于“线程”的简单机制，用于防止MPLS建立具有环路的标签交换路径（LSP）。
When an LSR finds that it has a new next hop for a particular FEC (Forwarding Equivalence Class) [1], it creates a thread and extends it downstream. Each such thread is assigned a unique "color", such that no two threads in the network can have the same color.
当LSR发现它具有特定FEC（转发等价类）[1]的新下一跳时，它将创建一个线程并将其扩展到下游。每个这样的线程被分配一个唯一的“颜色”，这样网络中的两个线程就不能有相同的颜色。
For a given LSP, once a thread is extended to a particular next hop, no other thread is extended to that next hop unless there is a change in the hop count from the furthest upstream node. The only state information that needs to be associated with a particular next hop for a particular LSP is the thread color and hop count.
对于给定的LSP，一旦一个线程扩展到特定的下一个跃点，除非最远的上游节点的跃点计数发生变化，否则不会有其他线程扩展到该下一个跃点。需要与特定LSP的特定下一跳关联的唯一状态信息是线程颜色和跳数。
If there is a loop, then some thread will arrive back at an LSR through which it has already passed. This is easily detected, since each thread has a unique color.
如果有一个循环，那么一些线程将返回到它已经通过的LSR。这很容易检测到，因为每个线程都有一个唯一的颜色。
Section 3 and 4 provide procedures for determining that there is no loop. When this is determined, the threads are "rewound" back to the point of creation. As they are rewound, labels get assigned. Thus labels are NOT assigned until loop freedom is guaranteed.
第3节和第4节提供了确定不存在回路的程序。当确定这一点时，线程将“重新缠绕”回创建点。当标签被重新卷绕时，标签将被指定。因此，在保证循环自由度之前，不会指定标签。
While a thread is extended, the LSRs through which it passes must remember its color and hop count, but when the thread has been rewound, they need only remember its hop count.
当一个线程被扩展时，它经过的LSR必须记住它的颜色和跳数，但是当线程被重绕时，它们只需要记住它的跳数。
The thread mechanism works if some, all, or none of the LSRs in the LSP support VC-merge. It can also be used with either the ordered downstream on-demand label allocation or ordered downstream unsolicited label allocation [2,3]. The mechanism can also be applicable to loop detection, old path retention, and load-splitting.
如果LSP中的某些、所有或任何LSR都不支持VC合并，则线程机制可以工作。它还可用于订购的下游按需标签分配或订购的下游非请求标签分配[2,3]。该机制还可用于循环检测、旧路径保留和负载拆分。
The state information which must be carried in protocol messages, and which must be maintained internally in state tables, is of fixed size, independent of the network size. Thus the thread mechanism is more scalable than alternatives which require that path-vectors be carried.
必须在协议消息中携带并且必须在状态表中内部维护的状态信息具有固定大小，与网络大小无关。因此，线程机制比需要携带路径向量的替代方案更具可伸缩性。
To set up a new LSP after a routing change, the thread mechanism requires communication only between nodes which are downstream of the point of change. There is no need to communicate with nodes that are upstream of the point of change. Thus the thread mechanism is more robust than alternatives which require that a diffusion computation be performed (see section 9).
要在路由更改后建立新的LSP，线程机制只需要在更改点下游的节点之间进行通信。不需要与变更点上游的节点通信。因此，线程机制比要求进行扩散计算的替代方案更为稳健（见第9节）。
LSP
LSP
We will use the term LSP to refer to a multipoint-to-point tree whose root is the egress node. See section 3.5 of [3].
我们将使用术语LSP来表示根为出口节点的多点对点树。见[3]第3.5节。
In the following, we speak as if there were only a single LSP being set up in the network. This allows us to talk of incoming and outgoing links without constantly saying something like "for the same LSP.
在下面的例子中，我们说的好像网络中只设置了一个LSP。这使我们能够谈论传入和传出链接，而不必不断地说“对于相同的LSP”。
Incoming Link, Upstream Link Outgoing Link, Downstream Link
传入链路、上行链路、传出链路、下行链路
At a given node, a given LSP will have one or more incoming, or upstream links, and one outgoing or downstream link. A "link" is really an abstract relationship with an "adjacent" LSR; it is an "edge" in the "tree", and not necessarily a particular concrete entity like an "interface".
在给定的节点上，给定的LSP将具有一个或多个传入或上行链路，以及一个传出或下行链路。“链接”实际上是与“相邻”LSR的抽象关系；它是“树”中的一个“边”，而不一定是像“接口”这样的特定具体实体。
Leaf Node, Ingress Node
叶节点，入口节点
A node which has no upstream links.
没有上行链路的节点。
Eligible Leaf Node
合格叶节点
A node which is capable of being a leaf node. For example, a node is not an eligible leaf node if it is not allowed to directly inject L3 packets created or received at the node into its outgoing link.
能够成为叶节点的节点。例如，如果不允许节点将在该节点创建或接收的L3数据包直接注入其传出链路，则该节点不是合格的叶节点。
Link Hop Count
链路跳数
Every link is labeled with a "link hop count". This is the number of hops between the given link and the leaf node which is furthest upstream of the given link. At any node, the link hop count for the downstream link is one more than the largest of the hop counts associated with the upstream links.
每个链接都标有“链接跳数”。这是给定链路和位于给定链路最远上游的叶节点之间的跳数。在任何节点上，下游链路的链路跳数比与上游链路相关联的最大跳数多一个。
We define the quantity "Hmax" at a given node to be the maximum of all the incoming link hop counts. Note that, the link hop count of the downstream link is equal to Hmax+1. At a leaf node, Hmax is set to be zero.
我们将给定节点的数量“Hmax”定义为所有传入链路跳数的最大值。注意，下游链路的链路跳数等于Hmax+1。在叶节点上，Hmax设置为零。
An an example of link hop counts is shown in Fig.1.
链路跳数示例如图1所示。
1 2
A---B---C K
| |
|3 |1
| |
| 4 5 | 6 7
D---G---H---I---J
|
|2
1 |
E---F
1 2
A---B---C K
| |
|3 |1
| |
| 4 5 | 6 7
D---G---H---I---J
|
|2
1 |
E---F
Fig.1 Example of link hop counts
图1链路跳数的示例
Next Hop Acquisition
下一跳捕获
Node N thought that FEC F was unreachable, but now has a next hop for it.
节点N认为FEC F是不可到达的，但现在有了下一跳。
Next Hop Loss
下一跳损失
Node N thought that node A was the next hop for FEC F, but now no longer has the next hop for FEC F. A node loses a next hop whenever the next hop goes down.
节点N认为节点A是FEC F的下一个跃点，但现在不再具有FEC F的下一个跃点。每当下一个跃点下降时，节点就会丢失下一个跃点。
Next Hop Change
下一跳改变
At node N, the next hop for FEC F changes from node A to node B, where A is different than B. A next hop change event can be seen as a combination of a next hop loss event on the old next hop and a next hop acquisition event on the new next hop.
在节点N处，FEC F的下一跳从节点A改变到节点B，其中A不同于B。下一跳改变事件可被视为旧下一跳上的下一跳丢失事件和新下一跳上的下一跳获取事件的组合。
A thread is a sequence of messages used to set up an LSP, in the "ordered downstream-on-demand" (ingress-initiated ordered control) style.
线程是用于设置LSP的一系列消息，采用“按需有序下游”（入口启动的有序控制）样式。
There are three attributes related to threads. They may be encoded into a single thread object as:
有三个与线程相关的属性。它们可以被编码到单个线程对象中，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Color +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | TTL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Color +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | TTL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thread Color
线色
Every time a path control message is initiated by a node, the node assigns a unique "color" to it. This color is to be unique in both time and space: its encoding consists of an IP address of the node concatenated with a unique event identifier from a numbering space maintained by the node. The path setup messages that the node sends downstream will contain this color. Also, when the node sends such a message downstream, it will remember the color, and this color becomes the color of the downstream link.
每次节点启动路径控制消息时，节点都会为其指定唯一的“颜色”。此颜色在时间和空间上都是唯一的：其编码由节点的IP地址和节点维护的编号空间中的唯一事件标识符连接而成。节点向下游发送的路径设置消息将包含此颜色。此外，当节点向下游发送这样的消息时，它将记住颜色，并且该颜色将成为下游链接的颜色。
When a colored message is received, its color becomes the color of the incoming link. The thread which consists of messages of a certain color will be known as a thread of that color.
收到彩色消息时，其颜色将成为传入链接的颜色。由特定颜色的消息组成的线程称为该颜色的线程。
special color value "transparent"(=all 0's) is reserved.
保留特殊颜色值“透明”（=所有0）。
One possible method for unique color assignment is, starting the event identifier from its initial value, and incrementing it by one (modulo its maximum value) each time a color is assigned. In this method, the initial event identifier is either selected at random or assigned to be larger than the largest event identifier used on the previous system incarnation.
唯一颜色分配的一种可能方法是，从事件标识符的初始值开始，并在每次分配颜色时将其递增一（取其最大值的模）。在该方法中，初始事件标识符可以随机选择，也可以指定为大于先前系统化身上使用的最大事件标识符。
Thread Hop Count
线程跳数
In order to maintain link hop counts, we need to carry hop counts in the path control messages. For instance, a leaf node would assign a hop count of 1 to its downstream link, and would store that value into a path setup message it sends downstream. When a path setup message is sent downstream, a node would assign a hop count which is one more than the largest of the incoming link hop counts, to its downstream link, and would store that value into a path setup message it sends downstream. Once the value is stored in a path control message, we may refer to it has a "thread hop count".
为了保持链路跳数，我们需要在路径控制消息中携带跳数。例如，叶节点将为其下游链路分配1的跃点计数，并将该值存储到它向下游发送的路径设置消息中。当路径设置消息被发送到下游时，节点将为其下游链路分配一个跳数，该跳数比传入链路跳数的最大值多一个，并将该值存储到它向下游发送的路径设置消息中。一旦该值存储在路径控制消息中，我们可以将其称为具有“线程跳数”。
A special hop count value "unknown"(=0xff), which is larger than any other known value, is used when a loop is found. Once the thread hop count is "unknown", it is not increased any more as the thread is extended.
当发现循环时，使用比任何其他已知值都大的特殊跃点计数值“unknown”（=0xff）。一旦线程跃点计数为“未知”，它就不会随着线程的扩展而增加。
Thread TTL
线程TTL
To avoid infinite looping of control messages in some cases, a thread TTL is used. When a node creates a path control message and sends it downstream, it sets a TTL to the message, and the TTL is decremented at each hop. When the TTL reaches 0, the message is not forwarded any more. Unlike the thread hop counts and the thread colors, the thread TTLs do not needs to be stored in incoming links.
为了避免在某些情况下控制消息的无限循环，使用了线程TTL。当节点创建路径控制消息并将其发送到下游时，它会为该消息设置一个TTL，并且该TTL在每个跃点处递减。当TTL达到0时，消息不再转发。与线程跃点计数和线程颜色不同，线程TTL不需要存储在传入链接中。
When the same colored thread is received on multiple incoming links, or the received thread color was assigned by the receiving node, it is said that the thread forms a loop. A thread creator can tell whether it assigned the received thread color by checking the IP address part of the received thread color.
当在多个传入链接上接收到相同颜色的线程时，或者接收节点分配了接收到的线程颜色，则表示该线程形成了一个循环。线程创建者可以通过检查接收到的线程颜色的IP地址部分来判断是否分配了接收到的线程颜色。
Five primitive actions are defined in order to prevent LSP loops by using threads: "extending", "rewinding", "withdrawing", "merging", and "stalling". This section describes only each primitive action and does not describe how these primitive actions are combined and how the algorithm totally works. The main body of the algorithm is described in section 4.
为了通过使用线程防止LSP循环，定义了五个基本动作：“扩展”、“倒带”、“收回”、“合并”和“暂停”。本节仅描述每个基本动作，不描述这些基本动作是如何组合的以及算法是如何整体工作的。第4节描述了算法的主体。
Thread Extending
螺纹延伸
When a node starts to send a path setup message to its next hop with a set of thread attributes, it is said that "the node creates a thread and extends it downstream". When a node receives a path setup message from an upstream node with a set of thread attributes and forwards it downstream, it is said that "the node receives a thread and extends it downstream". The color and hop count of the thread become the color and hop count of the outgoing link. Whenever a thread is received on a particular link, the color and hop count of that thread become the color and hop count of that incoming link, replacing any color and hop count that the link may have had previously.
当节点开始向其下一跳发送带有一组线程属性的路径设置消息时，会说“节点创建了一个线程并将其扩展到下游”。当节点从具有一组线程属性的上游节点接收到路径设置消息并将其转发到下游时，称为“节点接收到线程并将其扩展到下游”。线程的颜色和跃点计数将成为传出链接的颜色和跃点计数。每当在特定链接上接收到线程时，该线程的颜色和跃点计数将成为该传入链接的颜色和跃点计数，取代该链接以前可能具有的任何颜色和跃点计数。
For example, when an ingress node initiates a path setup, it creates a thread and extends it downstream by sending a path setup message. The thread hop count is set to be 1, and the thread color is set to be the ingress node's address with an appropriate event identifier, and the thread TTL is set to be its maximum value.
例如，当入口节点启动路径设置时，它会创建一个线程，并通过发送路径设置消息将其扩展到下游。线程跃点计数设置为1，线程颜色设置为具有适当事件标识符的入口节点地址，线程TTL设置为其最大值。
When a node receives a thread and extends it downstream, the node either (i) extends the thread without changing color, or (ii) extend the thread with changing color. The received thread is extended with changing color if it is received on a new incoming link and extended on an already existing outgoing link, otherwise, it is extended without changing color. When a thread is extended with changing color, a new colored thread is created and extended.
当节点接收到线程并将其向下扩展时，该节点（i）在不更改颜色的情况下扩展线程，或（ii）在更改颜色的情况下扩展线程。如果接收到的线程在新的传入链接上接收并在现有的传出链接上扩展，则会通过更改颜色来扩展该线程，否则，将在不更改颜色的情况下扩展该线程。当线程随颜色变化而扩展时，将创建并扩展一个新的彩色线程。
Thread creation does not occur only at leaf nodes. If an intermediate node has an incoming link, it will create and extend a new thread whenever it acquires a new next hop.
线程创建不仅仅发生在叶节点上。如果中间节点有一个传入的链接，它将在获得新的下一跳时创建并扩展一个新线程。
When a node notifies a next hop node of a decrease of the link hop count, if it is not extending a colored thread, a transparent thread is extended.
当一个节点通知下一跳节点链接跳数减少时，如果它没有扩展有色线程，则扩展透明线程。
Thread Merging
线程合并
When a node which has a colored outgoing link receives a new thread, it does not necessarily extend the new thread. It may instead 'merge' the new threads into the existing outgoing thread. In this case, no messages are sent downstream. Also, if a new incoming thread is extended downstream, but there are already other incoming threads, these other incoming threads are considered to be merged into the new outgoing thread.
当具有彩色传出链接的节点接收到新线程时，它不一定扩展新线程。它可能会将新线程“合并”到现有的传出线程中。在这种情况下，不会向下游发送任何消息。此外，如果一个新的传入线程向下游扩展，但已经有其他传入线程，则这些其他传入线程将被视为合并到新的传出线程中。
Specifically, a received thread is merged if all the following conditions hold:
具体地说，如果满足以下所有条件，则合并接收到的线程：
o A colored thread is received by node N, AND o The thread does not form a loop, AND o N is not an egress node, AND o N's outgoing link is colored, AND o N's outgoing link hop count is at least one greater than the hop count of the newly received thread.
o 有色线程由节点N接收，并且o线程不形成循环，并且o N不是出口节点，并且o N的出站链路是有色的，并且o N的出站链路跳数至少比新接收的线程的跳数大一个。
When an outgoing thread rewinds (see below), any incoming threads which have been merged with it will rewind as well.
当传出线程倒带时（见下文），与之合并的任何传入线程也将倒带。
Thread Stalling
线程失速
When a colored thread is received, if the thread forms a loop, the received thread color and hop count are stored on the receiving link without being extended. This is the special case of thread merging applied only for threads forming a loop and referred to as the "thread stalling", and the incoming link storing the stalled thread is called "stalled incoming link". A distinction is made between stalled incoming links and unstalled incoming links.
当接收到彩色线程时，如果线程形成循环，则接收到的线程颜色和跃点计数将存储在接收链路上，而不进行扩展。这是线程合并的特殊情况，仅适用于形成循环的线程，称为“线程暂停”，存储暂停线程的传入链接称为“暂停传入链接”。对暂停的传入链接和未暂停的传入链接进行了区分。
Thread Rewinding
退线
When a thread reaches a node which satisfies a particular loop-free condition, the node returns an acknowledgment message back to the message initiator in the reverse path on which the thread was extended. The transmission of the acknowledgment messages is the "rewinding" of the thread.
当线程到达满足特定无循环条件的节点时，该节点以线程扩展的反向路径将确认消息返回给消息启动器。确认消息的传输是线程的“倒带”。
The loop-free condition is:
无循环条件为：
o A colored thread is received by the egress node, OR o All of the following conditions hold: (a) A colored thread is received by node N, AND (b) N's outgoing link is transparent, AND (c) N's outgoing link hop count is at least one greater than the hop count of the newly received thread.
o 出口节点接收有色线程，或者o以下所有条件均成立：（A）节点N接收有色线程，并且（b）N的传出链路是透明的，并且（c）N的传出链路跳数至少比新接收的线程的跳数大一个。
When a node rewinds a thread which was received on a particular link, it changes the color of that link to transparent.
当节点倒回在特定链接上接收到的线程时，它会将该链接的颜色更改为透明。
If there is a link from node M to node N, and M has extended a colored thread to N over that link, and M determines (by receiving a message from N) that N has rewound that thread, then M sets the color of its outgoing link to transparent. M then continues rewinding the thread, and in addition, rewinds any other incoming thread which had been merged with the thread being rewound, including stalled threads.
如果存在从节点M到节点N的链接，并且M已将有色线程扩展到该链接上的N，并且M确定（通过接收来自N的消息）N已将该线程重绕，则M将其传出链接的颜色设置为透明。然后M继续倒带线程，此外，倒带与正在倒带的线程合并的任何其他传入线程，包括暂停的线程。
Each node can start label switching after the thread colors in all incoming and outgoing links becomes transparent.
在所有传入和传出链接中的线程颜色变为透明后，每个节点都可以开始标签切换。
Note that transparent threads are threads which have already been rewound; hence there is no such thing as rewinding a transparent thread.
请注意，透明螺纹是已经重新缠绕的螺纹；因此，不存在倒带透明线这样的事情。
Thread Withdrawing
退线
It is possible for a node to tear down a path. A node tears down the portion of the path downstream of itself by sending teardown messages to its next hop. This process is known as the "thread withdrawing".
节点可以拆下路径。节点通过向其下一跳发送拆卸消息来拆卸其自身下游路径的一部分。这个过程称为“退线”。
For example, suppose a node is trying to set up a path, and then experiences a next hop change or a next hop loss. It will withdraw the thread that it had extended down its old next hop.
例如，假设一个节点尝试设置路径，然后经历下一跳更改或下一跳丢失。它将从旧的下一个跃点上收回已延伸的线程。
If node M has extended a thread to node N, and node M then withdraws that thread, N now has one less incoming link than it had before. If N now has no other unstalled incoming links and N is not an eligible leaf node, it must withdraw its outgoing thread. If N still has an unstalled incoming link or N is an eligible leaf node, it may (or may not) need to change the hop count of the outgoing link.
如果节点M将一个线程扩展到节点N，然后节点M退出该线程，那么节点N现在比以前少了一个传入链接。如果N现在没有其他未挂起的传入链接，并且N不是合格的叶节点，则它必须撤回其传出线程。如果N仍然有一个未挂起的传入链路，或者N是一个合格的叶节点，它可能（也可能不）需要更改传出链路的跃点计数。
N needs to change the outgoing hop count if:
N需要更改传出跃点计数，如果：
o The incoming link hop count that was just removed had a larger hop count than any of the remaining incoming links, AND o One of the following conditions holds: (a) The outgoing link is transparent, OR (b) The outgoing link has a known hop count.
o 刚刚删除的传入链路跃点计数比任何其他传入链路的跃点计数都大，并且o以下条件之一适用：（a）传出链路是透明的，或者（b）传出链路具有已知的跃点计数。
If the outgoing link is transparent, it remains transparent, but the new hop count needs to be sent downstream. If the outgoing link is colored, a new thread (with a new color) needs to be created and extended downstream.
如果传出链路是透明的，它将保持透明，但新的跃点计数需要发送到下游。如果传出链接是彩色的，则需要创建一个新线程（使用新颜色）并向下游扩展。
The following notations are used to illustrate examples of primitive actions defined for threads.
以下符号用于说明为线程定义的基本操作的示例。
A pair of thread attributes stored in each link is represented by "(C,H)", where C and H represent the thread color and thread hop count, respectively.
存储在每个链接中的一对线程属性由“（C，H）”表示，其中C和H分别表示线程颜色和线程跳数。
A thread marked "+" indicates that it is created or received now. A thread marked "-" indicates that it is withdrawn now.
标记为“+”的线程表示现在已创建或接收该线程。标有“-”的线程表示它现在已被撤回。
A link labeled with squared brackets (e.g., "[a]") indicates that it is an unstalled link. A link labeled with braces (e.g., "{a}") indicates that it is a stalled link.
用方括号（例如“[A]”）标记的链接表示它是未标记的链接。用大括号标记的链接（例如“{A}”）表示它是一个暂停的链接。
Fig. 2 shows an example in which a leaf node A creates a blue thread and extends it downstream.
图2示出了叶节点a创建蓝色线程并将其向下延伸的示例。
(bl,1)
A---[o1]--->
(bl,1)
A---[o1]--->
Fig.2 Thread extending at leaf node
图2叶节点处的螺纹延伸
Fig.3 shows an example of thread extending without changing color at intermediate node. Assume that a node B has no incoming and outgoing link before receiving a blue thread. When node B receives the blue thread of hop count 1 on a new incoming link i1, it extends the thread downstream without changing color (Fig.3(a)). After the blue thread is extended, node B receives a red thread of hop count unknown on incoming link i1 again (Fig.3(b)). The red thread is also extended without changing its color, since both i1 and o1 already exists.
图3显示了在中间节点处不改变颜色而延伸螺纹的示例。假设节点B在接收蓝色线程之前没有传入和传出链接。当节点B在新的传入链路i1上接收到跃点计数1的蓝色线程时，它将线程向下延伸而不改变颜色（图3（a））。在蓝色线程被扩展之后，节点B再次在传入链路i1上接收到跳数未知的红色线程（图3（B））。由于i1和o1都已存在，因此红线也在不改变颜色的情况下延伸。
(bl,1)+ (bl,2) (re,U)+ (re,U)
----[i1]--->B---[o1]----> ----[i1]--->B----[o1]--->
(bl,1)+ (bl,2) (re,U)+ (re,U)
----[i1]--->B---[o1]----> ----[i1]--->B----[o1]--->
Fig.3(a) Fig.3(b)
图3（a）图3（b）
Fig.3 Thread extending without changing color
图3不改变颜色的螺纹延伸
Fig.4 shows an example of thread extending with changing color. There are single incoming link i1 and single outgoing link o1 in Fig.4(a). Then a red thread of hop count 3 is received on a new incoming link i2. In this case, the received thread is extended with changing color, i.e., a new green thread is created and extended (Fig.4(b)), since o1 already exists.
图4显示了随颜色变化而延伸的螺纹示例。在图4（a）中有单个输入链路i1和单个输出链路o1。然后，在新的传入链路i2上接收跃点计数为3的红色线程。在这种情况下，接收到的线程会随着颜色的变化而扩展，即，由于o1已经存在，因此会创建并扩展一个新的绿色线程（图4（b））。
(bl,1) (bl,2) (bl,1) (gr,4)
----[i1]--->B----[o1]---> ----[i1]--->B----[o1]--->
^
|
----[i2]----+
(re,3)+
(bl,1) (bl,2) (bl,1) (gr,4)
----[i1]--->B----[o1]---> ----[i1]--->B----[o1]--->
^
|
----[i2]----+
(re,3)+
Fig.4(a) Fig.4(b)
图4（a）图4（b）
Fig.4 Thread extending with changing color
图4随颜色变化而延伸的螺纹
Fig.5 shows an example of thread merging. When a node B receives a red thread of hop count 3, the received thread is not extended since the outgoing link hop count is at least one greater than the received thread hop count. Both the red and blue threads will be rewound when the blue thread on outgoing link o1 is rewound.
图5显示了线程合并的示例。当节点B接收到跃点计数为3的红色线程时，接收到的线程不会扩展，因为传出链路跃点计数至少比接收到的线程跃点计数大一个。当传出链路o1上的蓝色线程被重新缠绕时，红色和蓝色线程都将被重新缠绕。
(bl,3) (bl,4)
----[i1]--->B----[o1]--->
^
|
----[i2]----+
(re,3)+
(bl,3) (bl,4)
----[i1]--->B----[o1]--->
^
|
----[i2]----+
(re,3)+
Fig.5 Thread merging
图5线程合并
Figs 6 and 7 show examples of thread stalling. When a node B receives a blue thread of hop count 10 on incoming link i2 in Fig.6, it "stalls" the received thread since the blue thread forms a loop. In Fig.7, a leaf node A finds the loop of its own thread.
图6和图7显示了螺纹失速的示例。当节点B在图6中的传入链路i2上接收到跃点计数为10的蓝色线程时，它会“暂停”接收到的线程，因为蓝色线程形成一个循环。在图7中，叶节点a找到自己线程的循环。
(bl,3) (bl,4)
----[i1]--->B----[o1]--->
^
|
----{i2}----+
(bl,10)+
(bl,3) (bl,4)
----[i1]--->B----[o1]--->
^
|
----{i2}----+
(bl,10)+
Fig.6 Thread stalling (1)
图6螺纹失速（1）
(bl,10)+ (bl,1)
----{i1}--->A----[o1]--->
(bl,10)+ (bl,1)
----{i1}--->A----[o1]--->
Fig.7 Thread stalling (2)
图7螺纹失速（2）
Fig.8 shows an example of thread rewinding. When the yellow thread which is currently being extended is rewound (Fig.8(a)), the node changes all the incoming and outgoing thread color to transparent, and propagates thread rewinding to upstream nodes (Fig.8(b)).
图8显示了线程倒带的示例。当当前正在扩展的黄色线程被重绕时（图8（a）），节点将所有传入和传出线程的颜色更改为透明，并将线程重绕传播到上游节点（图8（b））。
(bl,1) (ye,2) (tr,1) (tr,2)
----[i2]--->B----[o1]---> ----[i2]--->B----[o1]--->
^ ^
| |
----[i3]----+ ----[i3]----+
(ye,1) (tr,1)
(bl,1) (ye,2) (tr,1) (tr,2)
----[i2]--->B----[o1]---> ----[i2]--->B----[o1]--->
^ ^
| |
----[i3]----+ ----[i3]----+
(ye,1) (tr,1)
Fig.8(a) Fig.8(b)
图8（a）图8（b）
Fig.8 Thread rewinding
图8退线
Fig.9 shows an example of thread withdrawing. In Fig.9(a), the red thread on incoming link i2 is withdrawn. Then Hmax decreases from 3 to 1, and node B creates a new green thread and extends it downstream, as shown in Fig.9(b).
图9显示了退螺纹的示例。在图9（a）中，引入链路i2上的红线被撤回。然后Hmax从3减小到1，节点B创建一个新的绿色线程并将其向下延伸，如图9（B）所示。
(bl,1) (re,4) (bl,1) (gr,2)+
----[i1]--->B---[o1]---> ----[i1]--->B----[o1]--->
^
|
----[i2]----+
(re,3)-
(bl,1) (re,4) (bl,1) (gr,2)+
----[i1]--->B---[o1]---> ----[i1]--->B----[o1]--->
^
|
----[i2]----+
(re,3)-
Fig.9(a) Fig.9(b)
图9（a）图9（b）
Fig.9 Thread withdrawing (1)
图9退线（1）
Fig.10 shows another example of thread withdrawing. In Fig.10(a), the red thread on incoming link i3 is withdrawn. In this case, Hmax decreases from unknown to 1, however, no thread is extended as shown in Fig.10(b), since the outgoing link has a colored thread and the hop count is unknown.
图10显示了退线的另一个示例。在图10（a）中，引入链路i3上的红线被撤回。在这种情况下，Hmax从未知减少到1，但是，没有线程被扩展，如图10（b）所示，因为传出链路有一个彩色线程，跳数未知。
(bl,1) (re,U) (bl,1) (re,U)
----[i2]--->B----[o1]---> ----[i2]--->B----[o1]--->
^
|
----[i3]----+
(re,U)-
(bl,1) (re,U) (bl,1) (re,U)
----[i2]--->B----[o1]---> ----[i2]--->B----[o1]--->
^
|
----[i3]----+
(re,U)-
Fig.10(a) Fig.10(b)
图10（a）图10（b）
Fig.10 Thread withdrawing (2)
图10退线（2）
Fig.11 shows another example of thread withdrawing. In Fig.11(a), the transparent thread on incoming link i3 is withdrawn. In this case, a transparent thread is extended (Fig.11(b)), since Hmax decreases and the outgoing link is transparent.
图11显示了退线的另一个示例。在图11（a）中，引入链路i3上的透明线程被撤回。在这种情况下，一个透明线程被扩展（图11（b）），因为Hmax减小，输出链路是透明的。
(tr,1) (tr,U) (tr,1) (tr,2)+
----[i2]--->B----[o1]---> ----[i2]--->B----[o1]--->
^
|
----[i3]----+
(tr,U)-
(tr,1) (tr,U) (tr,1) (tr,2)+
----[i2]--->B----[o1]---> ----[i2]--->B----[o1]--->
^
|
----[i3]----+
(tr,U)-
Fig.11(a) Fig.11(b)
图11（a）图11（b）
Fig.11 Thread withdrawing (3)
图11退线（3）
The ordered downstream-on-demand allocation is assumed here, however, the algorithm can be adapted to the ordered downstream allocation, as shown in section 5.
此处假设按需订购下游分配，但是，该算法可适用于订购下游分配，如第5节所示。
In the algorithm, a next hop change event will be separated into two events: a next hop loss event on the old next hop and a next hop acquisition event on the new next hop, in this order.
在该算法中，下一跳更改事件将分为两个事件：旧下一跳上的下一跳丢失事件和新下一跳上的下一跳获取事件，按此顺序。
The following notations are defined:
定义了以下符号：
Hmax: the largest incoming link hop count Ni: the number of unstalled incoming links
Hmax：最大传入链接跃点计数Ni：未调用传入链接的数量
The thread algorithm is described as follows.
线程算法描述如下。
When a node acquires a new next hop, it creates a colored thread and extends it downstream.
当一个节点获得一个新的下一跳时，它会创建一个彩色线程并将其扩展到下游。
When a node loses a next hop to which it has extended a thread, it may withdraw that thread. As described in section 3, this may or may not cause the next hop to take some action. Among the actions the next hop may take are withdrawing the thread from its own next hop, or extending a new thread to its own next hop.
当节点丢失已扩展线程的下一跳时，它可能会撤回该线程。如第3节所述，这可能会也可能不会导致下一跳采取某些行动。下一个跃点可能采取的行动包括从自己的下一个跃点中退出线程，或者将新线程扩展到自己的下一个跃点。
A received colored thread is either stalled, merged, rewound, or extended. A thread with TTL zero is never extended.
接收到的彩色线程被暂停、合并、重绕或扩展。TTL为零的线程永远不会扩展。
When a received thread is stalled at a node, if Ni=0 and the node is not an eligible leaf node, initiate a thread withdrawing. Otherwise, if Ni>0 and the received thread hop count is not unknown, a colored thread of hop count unknown is created and extended. If the received thread hop count is unknown, no thread is extended and no further action is taken.
当接收到的线程在某个节点上暂停时，如果Ni=0且该节点不是合格的叶节点，则启动线程退出。否则，如果Ni>0且接收到的线程跃点计数不是未知的，则创建并扩展跃点计数未知的彩色线程。如果接收到的线程跃点计数未知，则不会扩展线程，也不会采取进一步的操作。
When a thread being extended is rewound, if the thread hop count is greater than one more than Hmax, a transparent thread of hop count (Hmax+1) is extended downstream.
当正在扩展的线程被重绕时，如果线程跃点计数大于Hmax的一个，则跃点计数（Hmax+1）的透明线程将向下游扩展。
When a node that has an transparent outgoing link receives a transparent thread, if Hmax decreases the node extends it downstream without changing color.
当具有透明传出链接的节点接收到透明线程时，如果Hmax减小，则该节点会将其向下延伸，而不会更改颜色。
The thread algorithm described in section 4 can be applied to various LSP management policies.
第4节中描述的线程算法可以应用于各种LSP管理策略。
The same thread algorithm is applicable to both LSP loop prevention and detection.
同一线程算法适用于LSP循环预防和检测。
In loop prevention mode, a node transmits a label mapping (including a thread object) for a particular LSP only when it rewinds the thread for that LSP. No mapping message is sent until the thread rewinds.
在循环防止模式中，节点仅在为特定LSP倒回线程时，才会传输该LSP的标签映射（包括线程对象）。在线程倒带之前，不会发送映射消息。
On the other hand, if a node operates in loop detection mode, it returns a label mapping message without a thread object immediately after receiving a colored thread. A node which receives a label mapping message that does not have a thread object will not rewind the thread.
另一方面，如果节点在循环检测模式下运行，则在接收到彩色线程后，它会立即返回一条没有线程对象的标签映射消息。接收到没有线程对象的标签映射消息的节点将不会回放线程。
When a route changes, one might want to continue to use the old path if the new route is looping. This is achieved simply by holding the label assigned to the downstream link on the old path until the thread being extended on the new route gets rewound. This is an implementation choice.
当路由发生更改时，如果新路由正在循环，则可能希望继续使用旧路径。这只需在旧路径上保持分配给下游链接的标签，直到在新路径上延伸的线程重新缠绕为止。这是一种实现选择。
The thread mechanism can be also adapted to ordered downstream allocation mode (or the egress-initiated ordered control) by regarding the event of newly receiving of a label mapping message [4] from the next hop as a next hop acquisition event.
通过将新接收到来自下一跳的标签映射消息[4]的事件视为下一跳获取事件，线程机制还可适于有序下游分配模式（或出口发起的有序控制）。
Note that a node which doesn't yet have an incoming link behaves as a leaf. In the case where the tree is being initially built up (e.g., the egress node has just come up), each node in turn will behave as a leaf for a short period of time.
请注意，尚未具有传入链接的节点的行为类似于叶。在最初构建树的情况下（例如，出口节点刚刚出现），每个节点将在短时间内作为一片叶子。
A leaf node can easily perform load splitting by setting up two different LSPs for the same FEC. The downstream links for the two LSPs are simply assigned different colors. The thread algorithm now prevents a loop in either path, but also allows the two paths to have a common downstream node.
通过为同一FEC设置两个不同的LSP，叶节点可以轻松地执行负载拆分。两个LSP的下游链路仅分配不同的颜色。线程算法现在防止在任一路径中出现循环，但也允许两条路径有一个公共的下游节点。
If some intermediate node wants to do load splitting, the following modification is made. Assume that there are multiple next hops for the same FEC. If there are n next hops for a particular FEC, the set of incoming links for that FEC's LSP can be partitioned into n subsets, where each subset can be mapped to a distinct outgoing link.
如果某个中间节点想要进行负载拆分，则进行以下修改。假设同一FEC有多个下一跳。如果特定FEC有n个下一跳，则该FEC的LSP的入站链路集可以划分为n个子集，其中每个子集可以映射到不同的出站链路。
This provides n LSPs for the FEC. Each such LSP uses a distinct color for its outgoing link. The thread algorithm now prevents a loop in any of the paths, but also allows two or more of the paths to have a common downstream node.
这为FEC提供了n个LSP。每个这样的LSP使用一种不同的颜色作为其传出链接。线程算法现在可以防止任何路径中出现循环，但也允许两个或多个路径具有公共下游节点。
In this case, an interesting situation may happen. Let's say that in Fig.12, node B has two incoming links, i1 and i2, and two outgoing links, o1 and o2, such that i1 is mapped to o1, while i2 is mapped to o2.
在这种情况下，可能会发生有趣的情况。假设在图12中，节点B有两个传入链路i1和i2，以及两个传出链路o1和o2，这样i1映射到o1，而i2映射到o2。
If a blue thread received on i1 and extended on o1 is again received at node B on i2, the blue thread is not regarded as forming a loop, since i1 and i2 are regarded as belonging to different subsets. Instead, the blue thread received on i2 is extended on o2. If the thread extended on o2 is rewound, a single loop-free LSP which traverses node B twice is established.
如果在i1上接收并在o1上扩展的蓝色线程在i2上的节点B处再次接收，则蓝色线程不被视为形成循环，因为i1和i2被视为属于不同的子集。相反，i2上接收的蓝色线程在o2上扩展。如果o2上扩展的线程被重新缠绕，则建立一个遍历节点B两次的无循环LSP。
+------------------...--------------------+
. (bl,3) (bl,4) |
. ----[i1]---+ +--[o1]---> .... --+
. \ /
. v /
| B
|
+-----------[i2]--->B----[o2]--->
(bl,10)+ (bl,11)
+------------------...--------------------+
. (bl,3) (bl,4) |
. ----[i1]---+ +--[o1]---> .... --+
. \ /
. v /
| B
|
+-----------[i2]--->B----[o2]--->
(bl,10)+ (bl,11)
Fig.12 Load splitting at intermediate node
图12中间节点处的荷载拆分
There is another type of load splitting, in which packets arrived at single incoming link can be label switched to any one of multiple outgoing links. This case does not seem to be a good load-splitting scheme, since the packet order in the same FEC is not preserved. Thus, this document does not focus on this case.
还有另一种类型的负载拆分，在这种拆分中，到达单个传入链路的数据包可以被标签切换到多个传出链路中的任何一个。这种情况似乎不是一种好的负载分割方案，因为同一FEC中的数据包顺序没有保留。因此，本文件不侧重于本案。
Whether that's a good type of load splitting or not, the fact remains that ATM-LSRs cannot load split like this because ATM switches just don't have the capability to make forwarding decisions on a per-packet basis.
无论这是否是一种好的负载拆分类型，事实仍然是ATM LSR不能像这样进行负载拆分，因为ATM交换机不具备根据每个数据包做出转发决策的能力。
In the algorithm, a thread of unknown hop count is extended when a thread loop is detected. This reduces the number of loop prevention
该算法在检测到线程循环时，对跳数未知的线程进行扩展。这减少了环路预防的数量
messages by merging threads (of known hop count) that are flowing inside or outside the loop. See Appendix A.12.
通过合并在循环内部或外部流动的线程（已知跳数）来发送消息。见附录A.12。
How can we be sure that an established path does not contain a loop when the outgoing link hop count is NOT "unknown"?
当传出链路跳数不是“未知”时，我们如何确保已建立的路径不包含循环？
Consider a sequence of LSRs <R1, ..., Rn>, such that there is a loop traversing the LSRs in the sequence. (I.e., packets from R1 go to R2, then to R3, etc., then to Rn, and then from Rn to R1.)
考虑LSR＜R1，…，RN>的序列，这样在序列中有一个遍历LSR的环路。（即，数据包从R1到R2，然后到R3等，然后到Rn，然后从Rn到R1。）
Suppose that the thread hop count of the link between R1 and R2 is k. Then by the above procedures, the hop counts between Rn and R1 must be k+n-1. But the algorithm also ensures that if a node has an incoming hop count of j, its outgoing link hop count must be at least of j+1. Hence, if we assume that the LSP established as a result of thread rewinding contains a loop, the hop counts between R1 and R2 must be at least k+n. From this we may derive the absurd conclusion that n=0, and we may therefore conclude that there is no such sequence of LSRs.
假设R1和R2之间链路的线程跳数为k。然后通过上述步骤，Rn和R1之间的跳数必须为k+n-1。但该算法还确保，如果节点的传入跳数为j，则其传出链路跳数必须至少为j+1。因此，如果我们假设由于线程倒带而建立的LSP包含一个循环，那么R1和R2之间的跳数必须至少为k+n。由此我们可以得出n=0的荒谬结论，因此我们可以得出结论，不存在这样的LSR序列。
An established path does not contain a loop as well, when the outgoing link hop count is "unknown". This is because a colored thread of unknown hop count is never rewound unless it reaches egress.
当传出链路跳数为“未知”时，已建立的路径也不包含循环。这是因为一个未知跳数的彩色线程，除非到达出口，否则永远不会重新缠绕。
Regardless of whether the thread hop count is known or unknown, if there is a loop, then some node in the loop will be the last node to receive a thread over a new incoming link. This thread will always arrive back at that node, without its color having changed. Hence the loop will always be detected by at least one of the nodes in the loop.
不管线程跳数是已知的还是未知的，如果存在循环，那么循环中的某个节点将是通过新的传入链接接收线程的最后一个节点。此线程将始终返回到该节点，而不会更改其颜色。因此，循环将始终由循环中的至少一个节点检测。
Since no node ever extends the same colored thread downstream twice, a thread loop is not detected unless there actually is an L3 routing loop.
由于没有节点将相同颜色的线程向下延伸两次，因此不会检测到线程循环，除非实际存在L3路由循环。
Once a thread is stalled in a loop, the thread (or the path setup request) effectively remains in the loop, so that a path reconfiguration (i.e., thread withdrawing on the old path and thread extending on the new path) can be issued from any node that may receive a route change event so as to break the loop.
一旦线程在循环中暂停，线程（或路径设置请求）将有效地保留在循环中，以便可以从可能接收路由更改事件的任何节点发出路径重新配置（即，在旧路径上退出线程，在新路径上扩展线程），从而中断循环。
In the algorithm, multiple thread color and/or hop count updates may happen if several leaf nodes start extending threads at the same time. How can we prevent multiple threads from looping unlimitedly?
在该算法中，如果多个叶节点同时开始扩展线程，则可能会发生多个线程颜色和/或跳数更新。如何防止多个线程无限循环？
First, when a node finds that a thread forms a loop, it creates a new thread of hop count "unknown". All the looping threads of a known hop count which later arrive at the node would be merged into this thread. Such a thread behaves like a thread absorber.
首先，当一个节点发现一个线程形成一个循环时，它会创建一个跳数为“未知”的新线程。随后到达节点的已知跃点计数的所有循环线程将合并到此线程中。这样的线程的行为类似于线程吸收器。
Second, the "thread extending with changing color" prevents two threads from chasing each other.
第二，“颜色变化的线延伸”防止两条线相互追逐。
Suppose that a received thread were always extended without changing color. Then we would encounter the following situation.
假设接收到的线程总是在不改变颜色的情况下进行扩展。然后我们会遇到以下情况。
G Y
| |
v v
R1------>R2
^ |
| v
R4<------R3
G Y
| |
v v
R1------>R2
^ |
| v
R4<------R3
Fig.13 Example of thread chasing
图13螺纹追逐的示例
In Fig.13, (1) node G acquires R1 as a next hop, and starts to extend a green thread of hop count 1, (2) node Y acquires R2 as a next hop, and starts to extend a yellow thread of hop count 1, and (3) both node G and node Y withdraws their threads before these threads go round.
在图13中，（1）节点G获取R1作为下一个跃点，并开始扩展跃点计数为1的绿色线程，（2）节点Y获取R2作为下一个跃点，并开始扩展跃点计数为1的黄色线程，以及（3）节点G和节点Y在这些线程循环之前都退出其线程。
In this case, the yellow and green threads would go round and get back to R2 and R1, respectively. When the threads get back to R2 and R1, however, the incoming links that store the yellow and green colors no longer exist. As a result, the yellow and green threads would chase each other forever in the loop.
在这种情况下，黄色和绿色线程将循环并分别返回R2和R1。但是，当线程返回到R2和R1时，存储黄色和绿色的传入链接将不再存在。因此，黄线和绿线将在循环中永远相互追逐。
However, since we have the "extending with changing color" mechanism, this does not actually happen. When a green thread is received at R2, R2 extends the thread with changing color, i.e., creates a new red thread and extends it. Similarly, when a yellow thread is received at R1, R1 creates a new purple thread and extends it. Thus, the thread loop is detected even after node G and node Y withdraw threads. This ensures that a thread is extended around the loop which has a color assigned by some node that is in the loop.
然而，由于我们有“随颜色变化而延伸”的机制，这实际上并没有发生。当R2接收到一个绿色线程时，R2通过改变颜色来扩展线程，即创建一个新的红色线程并扩展它。类似地，当R1接收到黄色线程时，R1创建一个新的紫色线程并扩展它。因此，即使在节点G和节点Y退出线程之后，也会检测到线程循环。这确保线程围绕循环扩展，循环中的某个节点指定了颜色。
There is at least one case even the "extending with changing color" mechanism cannot treat, that is, the "self-chasing" in which thread extending and thread withdrawing with regard to the same thread chase each other in a loop. This case would happen when a node withdraw a thread immediately after extending it into an L3 loop.
至少有一种情况，即使是“变色延伸”机制也无法处理，即“自追踪”，即针对同一线程的线程延伸和线程退出在一个循环中相互追逐。当节点将线程扩展到L3循环后立即收回线程时，就会发生这种情况。
A heuristics for self-chasing is to delay the execution of thread withdrawing at an initiating node of the thread withdrawing. Anyway, the thread TTL mechanism can eliminate any kind of thread looping.
一种用于自追踪的启发式方法是延迟线程撤回的起始节点处的线程撤回执行。无论如何，线程TTL机制可以消除任何类型的线程循环。
In this section, we show two examples to show how the algorithm can prevent LSP loops in given networks.
在本节中，我们将展示两个示例，说明该算法如何在给定网络中防止LSP循环。
We assume that the ordered downstream-on-demand allocation is employed, that all the LSPs are with regard to the same FEC, and that all nodes are VC-merge capable.
我们假设采用了有序的下游按需分配，所有LSP都与相同的FEC相关，并且所有节点都具有VC合并能力。
Consider an MPLS network shown in Fig.14 in which an L3 loop exists. Each directed link represents the current next hop of the FEC at each node. Now leaf nodes R1 and R6 initiate creation of an LSP.
考虑图14所示的MPLS网络，其中存在L3环路。每个定向链路表示每个节点上FEC的当前下一跳。现在，叶节点R1和R6开始创建LSP。
R11 ------- R10 <-------------------- R9
| | ^
| | |
| | |
v v |
R1 -------> R2 --------> R3 --------> R4 --------- R5
[leaf] ^
|
|
|
R6 -------> R7 --------> R8
[leaf]
R11 ------- R10 <-------------------- R9
| | ^
| | |
| | |
v v |
R1 -------> R2 --------> R3 --------> R4 --------- R5
[leaf] ^
|
|
|
R6 -------> R7 --------> R8
[leaf]
Fig. 14 Example MPLS network (1)
图14示例MPLS网络（1）
Assume that R1 and R6 send a label request message at the same time, and that the initial thread TTL is 255. First we show an example of how to prevent LSP loops.
假设R1和R6同时发送标签请求消息，并且初始线程TTL为255。首先，我们展示一个如何防止LSP循环的示例。
A set of thread attributes is represented by (color, hop count, TTL).
一组线程属性由（颜色、跃点计数、TTL）表示。
The request from R1 and R6 contains (re,1,255) and (bl,1,255), respectively.
来自R1和R6的请求分别包含（re，1255）和（bl，1255）。
Assume that R3 receives the request originated from R1 before receiving the request originated from R6. When R3 receives the first request with red thread, R3 forwards it with (re,3,253) without changing thread color, since both the receiving incoming link and the outgoing link are newly created. Then R3 receives the second request with blue thread. In this time, the outgoing link is already exists. Thus, R3 performs thread extending with changing color, i.e., creates a new brown thread and forwards the request with (br,4,255).
假设R3在接收来自R6的请求之前接收来自R1的请求。当R3接收到带有红色线程的第一个请求时，R3使用（re，3253）转发它，而不更改线程颜色，因为接收传入链接和传出链接都是新创建的。然后，R3接收到第二个带有蓝色线程的请求。此时，传出链接已存在。因此，R3通过改变颜色执行线程扩展，即创建一个新的棕色线程，并使用（br，4255）转发请求。
When R2 receives the request from R10 with (re,6,250), it finds that the red thread forms a loop, and stalls the red thread. Then, R2 creates a purple thread of hop count unknown and extends it downstream by sending a request with (pu,U,255) to R3, where "U" represents "unknown".
当R2收到来自R10的带有（re，6250）的请求时，它发现红色线程形成一个循环，并暂停红色线程。然后，R2创建一个跃点计数未知的紫色线程，并通过向R3发送一个带有（pu，U，255）的请求将其扩展到下游，其中“U”表示“未知”。
After that, R2 receives another request from R10 with (br,7,252). The brown thread is merged into purple thread. R2 sends no request to R3.
之后，R2接收来自R10的另一个请求（br，7252）。棕色的线合并成紫色的线。R2不向R3发送请求。
On the other hand, the purple thread goes round without changing color through existing links, and R2 finds the thread loop and stalls the purple thread. Since the received thread hop count is unknown, no thread is created any more. In this case no thread rewinding occurs. The current state of the network is shown in Fig.15.
另一方面，紫色线程通过现有链接循环而不改变颜色，R2找到线程循环并暂停紫色线程。由于接收到的线程跃点计数未知，因此不再创建线程。在这种情况下，不会发生线程倒带。网络的当前状态如图15所示。
*: location of thread stalling
*：线程暂停的位置
(pu,U)
R11 ------- R10 <-------------------- R9
| | ^
| |(pu,U)* |
| | |(pu,U)
v v |
R1 -------> R2 --------> R3 --------> R4 --------- R5
[leaf] (re,1) (pu,U) ^ (pu,U)
|
| (bl,3)
|
R6 -------> R7 --------> R8
[leaf] (bl,1) (bl,2)
(pu,U)
R11 ------- R10 <-------------------- R9
| | ^
| |(pu,U)* |
| | |(pu,U)
v v |
R1 -------> R2 --------> R3 --------> R4 --------- R5
[leaf] (re,1) (pu,U) ^ (pu,U)
|
| (bl,3)
|
R6 -------> R7 --------> R8
[leaf] (bl,1) (bl,2)
Fig.15 The network state
图15网络状态
Then R10 changes its next hop from R2 to R11.
然后R10将其下一个跃点从R2更改为R11。
Since R10 has a purple thread on the old downstream link, it first sends a path teardown message to the old next hop R2 for withdrawing the purple thread. Next, it creates a green thread of hop count unknown and sends a request with (gr,U,255) to R11.
由于R10在旧的下游链路上有一个紫色线程，因此它首先向旧的下一跳R2发送一个路径拆卸消息，以收回紫色线程。接下来，它创建一个跃点计数未知的绿色线程，并向R11发送一个带有（gr，U，255）的请求。
When R2 receives the teardown message from R10, R2 removes the stalled incoming link between R10 and R2.
当R2接收到来自R10的拆卸消息时，R2将删除R10和R2之间暂停的传入链路。
On the other hand, the green thread reaches R1 and Hmax is updated from zero to unknown. In this case, R1 performs thread extending with changing color since the thread is received on a new incoming link but extended on the already existing outgoing link. As a result, R1 creates an orange thread of hop count unknown and extend it to R2.
另一方面，绿色线程到达R1，Hmax从零更新为未知。在这种情况下，R1通过改变颜色执行线程扩展，因为线程在新的传入链接上接收，但在已经存在的传出链接上扩展。结果，R1创建了一个跃点计数未知的橙色线程，并将其扩展到R2。
The orange thread goes round through existing links without changing color, and finally it is stalled at R1.
橙色线程在现有链接中循环而不改变颜色，最后它在R1处暂停。
The state of the network is now shown in Fig.16.
网络的状态如图16所示。
*: location of thread stalling
*：线程暂停的位置
(or,U) (or,U)
R11 <------ R10 <-------------------- R9
| | ^
|(or,U)* | |
| | |(or,U)
v | |
R1 -------> R2 --------> R3 --------> R4 --------- R5
[leaf] (or,U) (or,U) ^ (or,U)
|
| (bl,3)
|
R6 -------> R7 --------> R8
[leaf] (bl,1) (bl,2)
(or,U) (or,U)
R11 <------ R10 <-------------------- R9
| | ^
|(or,U)* | |
| | |(or,U)
v | |
R1 -------> R2 --------> R3 --------> R4 --------- R5
[leaf] (or,U) (or,U) ^ (or,U)
|
| (bl,3)
|
R6 -------> R7 --------> R8
[leaf] (bl,1) (bl,2)
Fig.16 The network state
图16网络状态
Then R4 changes its next hop from R9 to R5.
然后R4将其下一跳从R9更改为R5。
Since R4 is extending an orange thread, it first sends a teardown message to the old next hop R9 to withdraw the orange thread on the old route. Next, it creates a yellow thread of hop count unknown, and sends a request message with (ye,U,255) to R5.
由于R4正在扩展一个橙色线程，它首先向旧的下一跳R9发送一个拆卸消息，以在旧路由上收回橙色线程。接下来，它创建一个跃点计数未知的黄色线程，并向R5发送一条带有（ye，U，255）的请求消息。
Since R5 is the egress node, the yellow thread rewinding starts. R5 returns a label mapping message. The thread rewinding procedure is performed at each node, as the label mapping message is returned upstream hop-by-hop.
由于R5是出口节点，黄线倒带开始。R5返回标签映射消息。线程倒带过程在每个节点上执行，因为标签映射消息逐跳返回上游。
If R1 receives a label mapping message before receiving the orange thread's withdrawal from R11, R1 returns a label mapping message to R11. On receiving the orange thread's withdrawal, R1 will create a transparent thread and extend it by sending an update message with (tr,1,255) in order to notify downstream of the known hop count.
如果R1在收到橙色线程从R11中退出之前收到标签映射消息，R1将向R11返回标签映射消息。在接收到橙色线程的退出时，R1将创建一个透明线程，并通过发送带有（tr，1255）的更新消息来扩展它，以便通知下游已知的跃点计数。
Otherwise, if R1 receives the orange thread's withdrawal before receiving a label mapping message, R1 removes the stalled incoming orange link and waits for rewinding of the outgoing orange thread. Finally, when R1 receives a label mapping message from R2, it creates a transparent thread (tr,1,255) and extend it downstream.
否则，如果R1在收到标签映射消息之前收到橙色线程的退出，R1将删除暂停的传入橙色链接，并等待传出橙色线程的倒带。最后，当R1从R2接收到标签映射消息时，它会创建一个透明线程（tr，1255）并将其扩展到下游。
In both cases, a merged LSP ((R1->R2),(R6->R7->R8))->R3->R4->R5) is established and every node obtains the correct link hop count. The final network state is shown in Fig.17.
在这两种情况下，都会建立一个合并的LSP（（R1->R2），（R6->R7->R8））->R3->R4->R5），并且每个节点都会获得正确的链路跳数。最终网络状态如图17所示。
R11 <------ R10 <-------------------- R9
| | |
| | |
| | |
v | |
R1 -------> R2 --------> R3 --------> R4 --------> R5
[leaf] (tr,1) (tr,2) ^ (tr,4) (tr,5)
|
| (tr,3)
|
R6 -------> R7 --------> R8
[leaf] (tr,1) (tr,2)
R11 <------ R10 <-------------------- R9
| | |
| | |
| | |
v | |
R1 -------> R2 --------> R3 --------> R4 --------> R5
[leaf] (tr,1) (tr,2) ^ (tr,4) (tr,5)
|
| (tr,3)
|
R6 -------> R7 --------> R8
[leaf] (tr,1) (tr,2)
Fig.17 The final network state
图17最终网络状态
+----- R6----> R7-----+
| |
| v
R1---->R2 R4----->R5
| ^
| |
+--------->R3---------+
+----- R6----> R7-----+
| |
| v
R1---->R2 R4----->R5
| ^
| |
+--------->R3---------+
Fig.18 Example MPLS network (2)
图18示例MPLS网络（2）
Assume that in Fig.18, there is an established LSP R1->R2->R3->R4- >R5, and the next hop changes at R2 from R3 to R6. R2 sends a request to R6 with a red thread (re,2,255). When the request with (re,4,253) reaches R4, it extends the thread to R5 with changing color. Thus, a new green thread is created at R4 and extended to R5 by sending an update message with (gr,5,255).
假设在图18中，存在已建立的LSP R1->R2->R3->R4->R5，并且下一跳在R2处从R3更改为R6。R2向R6发送带有红色线程的请求（re，2255）。当带有（re，4253）的请求到达R4时，它会通过改变颜色将线程扩展到R5。因此，在R4创建一个新的绿色线程，并通过使用（gr，5255）发送更新消息来扩展到R5。
When R5 receives the update, it updates the incoming link hop count to 5 and returns an ack (or a notification message with a success code) for the update. When R4 receives the ack for the update, it returns a label mapping message to R7.
当R5接收到更新时，它将传入的链路跃点计数更新为5，并返回更新的ack（或带有成功代码的通知消息）。当R4收到更新的ack时，它向R7返回一条标签映射消息。
When R2 receives the label mapping message on the new route, it sends a teardown message to R3. When R4 receives the teardown message, it does not sends an update to R5 since Hmax does not change. Now an established LSP R1->R2->R6->R7->R4->R5 is obtained.
当R2收到新路由上的标签映射消息时，它会向R3发送一条拆卸消息。当R4接收到拆卸消息时，它不会向R5发送更新，因为Hmax不会更改。现在获得已建立的LSP R1->R2->R6->R7->R4->R5。
Then, the next hop changes again at R2 from R6 to R3.
然后，下一个跃点在R2处再次从R6更改为R3。
R2 sends a request with a blue thread (bl,2,255) to R3. R3 forwards the request with (bl,3,254) to R4.
R2向R3发送带有蓝色线程（bl，2255）的请求。R3将带有（bl，3254）的请求转发给R4。
When R4 receives the request, it immediately returns a label mapping message to R3 since Hmax does not change.
当R4接收到请求时，它会立即将标签映射消息返回到R3，因为Hmax不会更改。
When R2 receives the label mapping message on the new route, it sends a teardown message to R6. The teardown message reaches R4, triggering an update message with a transparent thread (tr,4,255) to R5, since Hmax decreases from 4 to 3. R5 updates the incoming link hop count to 4 without returning an ack.
当R2接收到新路由上的标签映射消息时，它会向R6发送一条拆卸消息。teardown消息到达R4，触发一条更新消息，其中一个透明线程（tr，4255）到R5，因为Hmax从4减少到3。R5将传入的链路跃点计数更新为4，而不返回ack。
A thread control block (TCB) is maintained per LSP at each node and may contain the following information:
线程控制块（TCB）在每个节点上按照LSP进行维护，可能包含以下信息：
- FEC - State - Incoming links Each incoming link has the following attributes: o neighbor: upstream neighbor node address o color: received thread color o hop count: received thread hop count o label o S-flag: indicates a stalled link - Outgoing links Each outgoing link has the following attributes: o neighbor: downstream neighbor node address o color: received thread color o hop count: received thread hop count o label o C-flag: indicates the link to the current next hop
- FEC-状态-传入链接每个传入链接都具有以下属性：o邻居：上游邻居节点地址o颜色：接收线程颜色o跃点计数：接收线程跃点计数o标签o S标志：指示暂停的链接-传出链接每个传出链接都具有以下属性：o邻居：下游邻居节点地址o颜色：接收到的线程颜色o跃点计数：接收到的线程跃点计数o标签o C标志：指示指向当前下一个跃点的链接
If a transparent thread is received on an incoming link for which no label is assigned yet or a non-transparent color is stored, discard the thread without entering the FSM. An error message may be returned to the sender.
如果在尚未分配标签或存储非透明颜色的传入链接上接收到透明线程，则在不输入FSM的情况下丢弃该线程。可能会将错误消息返回给发件人。
Whenever a thread is received on an incoming link, the following actions are taken before entering the FSM: (1) Store the received thread color and hop count on the link, replacing the old thread color and hop count, and (2) set the following flags that are used for an event switch within "Recv thread" event (see section 8.1).
无论何时在传入链接上接收到线程，在进入FSM之前都会采取以下操作：（1）在链接上存储接收到的线程颜色和跃点计数，替换旧的线程颜色和跃点计数，以及（2）在“Recv thread”事件中设置用于事件切换的以下标志（参见第8.1节）。
o Color flag (CL-flag): Set if the received thread is colored. o Loop flag (LP-flag): Set if the received thread forms a loop. o Arrived on new link flag (NL-flag): Set if the received thread arrives on a new incoming link.
o 颜色标志（CL标志）：如果接收到的线程是彩色的，则进行设置。o循环标志（LP标志）：如果接收到的线程形成循环，则设置该标志。o到达新链接标志（NL标志）：如果接收到的线程到达新的传入链接，则设置该标志。
If LP-flag is set, there must be an incoming link L, other than the receiving link, which stores the same thread color as the received one. The TCB to which link L belongs is referred to as the "detecting TCB". If the receiving LSR is VC-merge capable, the detecting TCB and the receiving TCB is the same, otherwise, the two TCBs are different.
如果设置了LP标志，则必须有一个传入链接L，而不是接收链接，它存储与接收链接相同的线程颜色。链路L所属的TCB被称为“检测TCB”。如果接收LSR支持VC合并，则检测TCB和接收TCB相同，否则，两个TCB不同。
Before performing a thread extending, the thread TTL is decremented by one. If the resulting TTL becomes zero, the thread is not extended but silently discarded. Otherwise, the thread is extended and the extended thread hop count and color are stored into the outgoing link.
在执行线程扩展之前，线程TTL递减1。如果生成的TTL变为零，则不会扩展线程，而是以静默方式丢弃线程。否则，线程将被扩展，扩展的线程跃点计数和颜色将存储到传出链接中。
When a node receives a thread rewinding event, if the received thread color and the extending thread color are different, it discards the event without entering the FSM.
当节点接收到线程倒带事件时，如果接收到的线程颜色和扩展线程颜色不同，它将丢弃该事件而不进入FSM。
An event which is "scheduled" by an action in an FSM must be passed immediately after the completion of the action.
FSM中某项操作“安排”的事件必须在该操作完成后立即传递。
The following variables are used in the FSM:
FSM中使用了以下变量：
o Ni: number of unstalled incoming links o Hmax: largest incoming hop count o Hout: hop count of the outgoing link for the current next hop o Hrec: hop count of the received thread
o Ni：未挂起的传入链接数o Hmax：最大传入跃点计数o Hout：当前下一跳的传出链接跃点计数o Hrec：接收线程的跃点计数
In the FSM, if Hmax=unknown, the value for (Hmax+1) becomes the value reserved for unknown hop count plus 1. For example, if Hmax=unknown=255, the value (Hmax+1) becomes 256.
在FSM中，如果Hmax=unknown，则（Hmax+1）的值将成为为未知跃点计数加1保留的值。例如，如果Hmax=unknown=255，则值（Hmax+1）变为256。
A TCB has three states; Null, Colored, and Transparent. When a TCB is in state Null, there is no outgoing link and Ni=0. The state Colored means that the node is extending a colored thread on the outgoing link for the current next hop. The state Transparent means that the node is the egress node or the outgoing link is transparent.
TCB有三种状态；空、彩色和透明。当TCB处于Null状态时，没有传出链路，Ni=0。有色状态表示节点正在为当前下一跳扩展传出链路上的有色线程。状态透明意味着该节点是出口节点或传出链路是透明的。
The flag value "1" represents the flag is set, "0" represents the flag is not set, and "*" means the flag value is either 1 or 0.
标志值“1”表示标志已设置，“0”表示标志未设置，“*”表示标志值为1或0。
The FSM allows to have one transparent outgoing link on the old next hop and one colored outgoing link on the current next hop. However, it is not allowed to have a colored outgoing link on the old next hop.
FSM允许在旧下一跳上有一个透明的传出链接，在当前下一跳上有一个彩色传出链接。但是，不允许在旧的下一跳上有彩色的传出链接。
State Null:
状态为空：
Event Action New state Recv thread Flags CL LP NL 0 * * Do nothing. No change 1 0 * If the node is egress, start thread rewinding Transparent and change the color of the receiving link to transparent. Otherwise, extend the received thread without Colored changing color. 1 1 * Stall the received thread; if Hrec<unknown, No change schedule "Reset to unknown" event for the detecting TCB.
事件操作新状态Recv线程标志CL LP NL 0**不执行任何操作。无更改1 0*如果节点是出口，则开始线程倒带透明，并将接收链接的颜色更改为透明。否则，在不改变颜色的情况下扩展接收到的线程。1*暂停接收到的线程；如果Hrec<未知，则检测TCB的“重置为未知”事件没有更改计划。
Next hop If eligible-leaf, create a colored thread and Colored acquisition extend it.
下一步如果符合条件，创建一个彩色线程并扩展它。
Others Silently ignore the event. No change
其他人则默默地忽略了这一事件。不变
State Colored:
国家有色人种：
Event Action New state Recv thread Flags CL LP NL 0 * * If Hmax+1<Hout<unknown, create a colored No change thread and extend it. Otherwise, do nothing. 1 0 * If Hmax<Hout, merge the received thread. No change Otherwise, extend the thread with (if NL=1) or without (if NL=0) changing color. 1 1 * Stall the received thread. If Ni=0 and the node is not an eligible leaf, Null initiate thread withdrawing. If Ni>0 and Hrec<unknown, schedule "Reset to No change unknown" event for the detecting TCB. Otherwise, do nothing. No change
事件操作新状态Recv线程标志CL LP NL 0**如果Hmax+1<Hout<unknown，则创建一个彩色无更改线程并扩展它。否则，什么也不做。1 0*如果Hmax<Hout，则合并接收到的线程。无更改否则，通过（如果NL=1）或不通过（如果NL=0）更改颜色来扩展线程。1*暂停接收到的线程。如果Ni=0且节点不是合格的叶，则Null启动线程撤回。如果Ni>0且Hrec<unknown，则为检测TCB安排“重置为无变化未知”事件。否则，什么也不做。不变
Rewound Propagate thread rewinding to previous hops Transparent that are extending a colored thread; change the colors stored in all incoming and outgoing links to transparent; if Hmax+1<Hout, extend transparent thread. Withdraw the thread on the outgoing link for which C-flag=0.
重绕传播线程重绕到扩展彩色线程的前一个透明跃点；将所有传入和传出链接中存储的颜色更改为透明；如果Hmax+1<Hout，则延伸透明螺纹。收回C-flag=0的传出链接上的线程。
Withdrawn Remove the corresponding incoming link. If Ni=0 and the node is not an eligible leaf, Null propagate thread withdrawing to all next hops. Otherwise, if Hmax+1<Hout<unknown, create No change a colored thread and extend it. Otherwise, do nothing. No change
删除相应的传入链接。如果Ni=0且节点不是合格的叶，则Null会将线程传播到所有下一个跃点。否则，如果Hmax+1<Hout<unknown，则创建不更改颜色的线程并扩展它。否则，什么也不做。不变
Next hop If there is already an outgoing link for the Transparent acquisition next hop, do nothing. (This case happens only when the node retains the old path.) Otherwise, create a colored thread and extend No change it.
下一个跃点如果透明采集下一个跃点已经有传出链接，则什么也不做。（只有当节点保留旧路径时才会发生这种情况。）否则，请创建一个彩色线程，并延伸而不更改它。
Next hop If the outgoing link is transparent and the No change loss node is allowed to retain the link and the next hop is alive, do nothing. Otherwise, take the following actions. Initiate thread withdrawing for the next hop; if the node becomes a new egress, schedule "Rewound" event for this TCB. If Ni=0, move to Null. Null Otherwise, do nothing. No change
下一跳如果传出链接是透明的，并且不允许更改丢失节点保留该链接，并且下一跳是活动的，则不执行任何操作。否则，请执行以下操作。为下一跳启动线程退出；如果节点成为新出口，则为此TCB安排“重绕”事件。如果Ni=0，则移动到Null。否则，什么也不做。不变
Reset to Create a colored thread of hop count unknown No change unknown and extend it.
重置以创建跃点计数未知的彩色线程，无更改未知并扩展它。
Others Silently ignore the event. No change
其他人则默默地忽略了这一事件。不变
State Transparent:
国家透明：
Event Action New state Recv thread Flags CL LP NL 0 * * If Hmax+1<Hout, extend a transparent thread. No change 1 0 * If the node is egress or if Hmax<Hout, change No change the color of the receiving link to transparent and start thread rewinding. Otherwise, extend the thread with (if NL=1) Colored or without (if NL=0) changing color.
事件操作新状态Recv线程标志CL LP NL 0**如果Hmax+1<Hout，则扩展透明线程。无更改1 0*如果节点为出口或如果Hmax<Hout，则无更改接收链接的颜色为透明，并开始线程倒带。否则，使用（如果NL=1）颜色或不更改（如果NL=0）颜色来扩展线程。
Withdrawn Remove the corresponding incoming link. If Ni=0 and the node is not an eligible leaf, Null propagate thread withdrawing to next hops. Otherwise, if Hmax+1<Hout, create No change a transparent thread and extend it. Otherwise, do nothing. No change
删除相应的传入链接。如果Ni=0且节点不是合格的叶，则Null会将线程传播到下一个跃点。否则，如果Hmax+1<Hout，则创建一个透明线程并扩展它。否则，什么也不做。不变
Next hop Create a colored thread and extend it. Colored acquisition
下一步创建一个彩色线程并扩展它。彩色采集
Next hop If the node is allowed to retain the outgoing No change loss link and the next hop is alive, do nothing. Otherwise, take the following actions. Initiate thread withdrawing. If Ni=0, move to Null. Null Otherwise, do nothing. No change
下一跳如果允许节点保留传出的无更改丢失链接，并且下一跳处于活动状态，则不执行任何操作。否则，请执行以下操作。启动线程退出。如果Ni=0，则移动到Null。否则，什么也不做。不变
Others Silently ignore the event. No change
其他人则默默地忽略了这一事件。不变
o Whereas the size of the path-vector increases with the length of the LSP, the sizes of the threads are constant. Thus the size of messages used by the thread algorithm are unaffected by the network size or topology. In addition, the thread merging capability reduces the number of outstanding messages. These lead to improved scalability.
o 虽然路径向量的大小随着LSP的长度而增加，但线程的大小是恒定的。因此，线程算法使用的消息大小不受网络大小或拓扑结构的影响。此外，线程合并功能减少了未处理消息的数量。这些改进了可伸缩性。
o In the thread algorithm, a node which is changing its next hop for a particular LSP must interact only with nodes that are between it and the LSP egress on the new path. In the path-vector algorithm, however, it is necessary for the node to initiate a diffusion computation that involves nodes which do not lie between it and the LSP egress.
o 在线程算法中，为特定LSP更改下一跳的节点必须仅与位于它和新路径上的LSP出口之间的节点交互。然而，在路径向量算法中，节点必须发起扩散计算，该计算涉及不位于其和LSP出口之间的节点。
This characteristic makes the thread algorithm more robust. If a diffusion computation is used, misbehaving nodes which aren't even in the path can delay the path setup. In the thread algorithm, the only nodes which can delay the path setup are those nodes which are actually in the path.
这个特性使得线程算法更加健壮。如果使用扩散计算，甚至不在路径中的行为不端的节点可能会延迟路径设置。在线程算法中，唯一可以延迟路径设置的节点是那些实际位于路径中的节点。
o The thread algorithm is well suited for use with both the ordered downstream-on-demand allocation and ordered downstream allocation. The path-vector/diffusion algorithm, however, is tightly coupled with the ordered downstream allocation.
o 线程算法非常适合于按需有序下游分配和有序下游分配。然而，路径向量/扩散算法与有序下游分配紧密耦合。
o The thread algorithm is retry-free, achieving quick path (re)configuration. The diffusion algorithm tends to delay the path reconfiguration time, since a node at the route change point must to consult all its upstream nodes.
o 线程算法无需重试，可实现快速路径（重新）配置。扩散算法倾向于延迟路径重构时间，因为路由改变点处的节点必须咨询其所有上游节点。
o In the thread algorithm, the node can continue to use the old path if there is an L3 loop on the new path, as in the path-vector algorithm.
o 在线程算法中，如果新路径上存在L3循环，则节点可以继续使用旧路径，如路径向量算法中所示。
The use of the procedures specified in this document does not have any security impact other than that which may generally be present in the use of any MPLS procedures.
使用本文件中规定的程序不会产生任何安全影响，但使用任何MPLS程序时通常会产生的影响除外。
Toshiba and/or Cisco may seek patent or other intellectual property protection for some of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Toshiba and/or Cisco, Toshiba and/or Cisco intend to disclose those patents and license them on reasonable and non-discriminatory terms.
东芝和/或思科可能会就本文件中披露的某些技术寻求专利或其他知识产权保护。如果本文件产生的任何标准受到或变得受到东芝和/或思科的一项或多项专利的保护，东芝和/或思科打算披露这些专利，并以合理和非歧视性的条款对其进行许可。
We would like to thank Hiroshi Esaki, Bob Thomas, Eric Gray, and Joel Halpern for their comments.
我们要感谢伊崎博史、鲍勃·托马斯、埃里克·格雷和乔尔·哈尔潘的评论。
Yoshihiro Ohba Toshiba Corporation 1, Komukai-Toshiba-cho, Saiwai-ku Kawasaki 210-8582, Japan
日本川崎市西围区Komukai Toshiba cho大叶东芝公司1号，邮编：210-8582
EMail: yoshihiro.ohba@toshiba.co.jp
EMail: yoshihiro.ohba@toshiba.co.jp
Yasuhiro Katsube Toshiba Corporation 1, Toshiba-cho, Fuchu-shi, Tokyo, 183-8511, Japan
东芝公司1号，东芝町，福珠市，东京，183-8511
EMail: yasuhiro.katsube@toshiba.co.jp
EMail: yasuhiro.katsube@toshiba.co.jp
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Eric Rosen Cisco Systems，Inc.马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Paul Doolan Ennovate Networks 330 Codman Hill Rd Marlborough MA 01719
马萨诸塞州马尔伯勒市科德曼山路330号保罗·杜兰·恩诺瓦特网络公司01719
EMail: pdoolan@ennovatenetworks.com
EMail: pdoolan@ennovatenetworks.com
[1] Callon, R., et al., "A Framework for Multiprotocol Label Switching", Work in Progress.
[1] Callon，R.等人，“多协议标签交换框架”，正在进行中。
[2] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[2] Davie，B.，Lawrence，J.，McCloghrie，K.，Rosen，E.，Swallow，G.，Rekhter，Y.和P.Doolan，“使用LDP和ATM VC交换的MPLS”，RFC 3035，2001年1月。
[3] Rosen, E., et al., "A Proposed Architecture for MPLS", Work in Progress.
[3] Rosen，E.等人，“MPLS的拟议架构”，正在进行中。
[4] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[4] Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
Appendix A - Further discussion of the algorithm
附录A-算法的进一步讨论
The purpose of this appendix is to give a more informal and tutorial presentation of the algorithm, and to provide some of the motivation for it. For the precise specification of the algorithm, the FSM should be taken as authoritative.
本附录的目的是对该算法进行更为非正式的教程演示，并为其提供一些动机。对于算法的精确说明，应将FSM视为权威。
As in the body of the document, we speak as if there is only one LSP; otherwise we would always be saying "... of the same LSP". We also consider only the case where the algorithm is used for loop prevention, rather than loop detection.
正如在文件正文中一样，我们说话时好像只有一个LSP；否则我们总是会说“…同一个LSP”。我们也仅考虑算法用于环路防止而不是环路检测的情况。
As a starting point, let's consider an algorithm which we might call "loop prevention by brute force". In this algorithm, every path setup attempt must go all the way to the egress and back in order for the path to be setup. This algorithm is obviously loop-free, by virtue of the fact that the setup messages actually made it to the egress and back.
作为一个出发点，让我们考虑一种算法，我们可以称之为“蛮力循环预防”。在该算法中，每次路径设置尝试都必须一直到出口并返回，以便设置路径。该算法显然是无循环的，因为设置消息实际上到达了出口和出口。
Consider, for example, an existing LSP B-C-D-E to egress node E. Now node A attempts to join the LSP. In this algorithm, A must send a message to B, B to C, C to D, D to E. Then messages are sent from E back to A. The final message, from B to A, contains a label binding, and A can now join the LSP, knowing that the path is loop-free.
例如，考虑到出口节点E的现有LSP B-C-DE，现在节点A尝试加入LSP。在该算法中，A必须向B、B到C、C到D、D到E发送消息。然后，消息从E发送回A。最后一条消息（从B到A）包含标签绑定，A现在可以加入LSP，知道路径是无循环的。
Using our terminology, we say that A created a thread and extended it downstream. The thread reached the egress, and then rewound.
使用我们的术语，我们说A创建了一个线程并将其扩展到下游。线到了出口，然后又重新绕了起来。
We needn't assume, in the above example, that A is an ingress node. It can be any node which acquires or changes its next hop for the LSP in question, and there may be nodes upstream of it which are also trying to join the LSP.
在上面的示例中，我们不需要假设A是入口节点。它可以是为所讨论的LSP获取或更改其下一跳的任何节点，并且它的上游也可能有尝试加入LSP的节点。
It is clear that if there is a loop, the thread never reaches the egress, so it does not rewind. What does happen? The path setup messages just keep traveling around the loop. If one keeps a hop count in them, one can ensure that they stop traveling around the loop when the hop count reaches a certain maximum value. That is, when one receives a path setup message with that the maximum hop count value, one doesn't send a path setup message downstream.
很明显，如果存在循环，线程永远不会到达出口，因此它不会倒带。发生了什么事？路径设置消息只是在循环中不断传播。如果在循环中保持跳数，则可以确保在跳数达到某个最大值时停止循环。也就是说，当接收到具有最大跃点计数值的路径设置消息时，不会向下游发送路径设置消息。
How does one recover from this situation of a looping thread? In order for L3 routing to break the loop, some node in the loop MUST experience a next hop change. This node will withdraw the thread
如何从循环线程的这种情况中恢复？为了使L3路由中断循环，循环中的某些节点必须经历下一跳更改。此节点将撤回线程
from its old next hop, and extend a thread down its new next hop. If there is no longer a loop, this thread now reaches the egress, and gets rewound.
从旧的下一个跃点开始，并沿新的下一个跃点延伸线程。如果不再存在循环，则该线程现在到达出口，并重新缠绕。
Consider this example:
考虑这个例子：
A | B--D--E | C
A | B--D--E | C
If A and C both attempt to join the established B-D-E path, then B and D must keep state for both path setup attempts, the one from A and the one from C. That is, D must keep track of two threads, the A-thread and the C-thread. In general, there may be many more nodes upstream of B who are attempting to join the established path, and D would need to keep track of them all.
如果A和C都试图加入已建立的B-D-E路径，则B和D必须保持两个路径设置尝试的状态，一个来自A，一个来自C。也就是说，D必须跟踪两个线程，A线程和C线程。通常，B的上游可能有更多的节点试图加入已建立的路径，D需要跟踪所有节点。
If VC merge is not being used, this isn't actually so bad. Without VC merge, D really must support one LSP for each upstream node anyway. If VC merge is being used, however, supporting an LSP requires only that one keep state for each upstream link. It would be advantageous if the loop prevention technique also required that the amount of state kept by a node be proportional to the number of upstream links which thenode has, rather than to the number of nodes which are upstream in the LSP.
如果没有使用VC merge，这实际上并没有那么糟糕。没有VC merge，D实际上必须为每个上游节点支持一个LSP。但是，如果正在使用VC merge，则支持LSP只需要每个上游链路有一个保持状态。如果环路预防技术还要求节点保持的状态量与节点具有的上游链路的数量成比例，而不是与LSP中上游的节点数量成比例，则这将是有利的。
Another problem is that if there is a loop, the setup messages keep looping. Even though a thread has traversed some node twice, the node has no way to tell that a setup message it is currently receiving is part of the same thread as some setup message it received in the past.
另一个问题是，如果存在循环，设置消息将继续循环。即使一个线程已经遍历了某个节点两次，该节点也无法判断它当前接收的设置消息与它过去接收的某个设置消息是同一线程的一部分。
Can we modify this brute force scheme to eliminate these two problems? We can. To show how to do this, we introduce two notions: thread hop count, and thread color.
我们可以修改这个暴力方案来消除这两个问题吗？我们可以。为了说明如何做到这一点，我们引入了两个概念：线程跳数和线程颜色。
Suppose every link in an LSP tree is labeled with the number of hops you would traverse if you were to travel backwards (upstream) from that link to the leaf node which is furthest upstream of the link.
假设LSP树中的每个链接都标记有跳数，如果要从该链接向后（上游）移动到该链接上游最远的叶节点，则要通过跳数。
For example, the following tree would have its links labeled as follows:
例如，以下树的链接标记如下：
1 2
A---B---C K
| |
|3 |1
| |
| 4 5 | 6 7
D---G---H---I---J
|
|2
1 |
E---F
1 2
A---B---C K
| |
|3 |1
| |
| 4 5 | 6 7
D---G---H---I---J
|
|2
1 |
E---F
Call these the "link hop counts".
这些称为“链路跳数”。
Links AB, EF, KH are labeled one, because you can go only one hop upstream from these links. Links BC, and FD are labeled 2, because you can go 2 hops upstream from these links. Link DG is labeled 4, because it is possible to travel 4 hops upstream from this link, etc.
链接AB、EF、KH标记为一，因为您只能从这些链接向上游跳一步。链接BC和FD标记为2，因为您可以从这些链接上行2跳。链路DG标记为4，因为可以从该链路上行4跳，以此类推。
Note that at any node, the hop count associated with the downstream link is one more than the largest of the hop counts associated with the upstream links.
注意，在任何节点上，与下游链路相关联的跃点计数比与上游链路相关联的最大跃点计数多一个。
Let's look at a way to maintain these hop counts.
让我们来看一种保持这些跃点计数的方法。
In order to maintain the link hop counts, we need to carry hop counts in the path setup messages. For instance, a node which has no upstream links would assign a hop count of 1 to its downstream link, and would store that value into the path setup messages it sends downstream. Once the value is stored in a path setup message, we may refer to it has a "thread hop count".
为了保持链路跳数，我们需要在路径设置消息中携带跳数。例如，没有上游链路的节点将为其下游链路分配1的跃点计数，并将该值存储到它向下游发送的路径设置消息中。一旦该值存储在路径设置消息中，我们可以将其称为具有“线程跃点计数”。
When a path setup message is received, the thread hop count is stored as the link hop count of the upstream link over which the message was received.
当接收到路径设置消息时，线程跃点计数存储为接收消息的上行链路的链路跃点计数。
When a path setup message is sent downstream, the downstream link's hop count (and the thread hop count) is set to be one more than the largest of the incoming link hop counts.
当路径设置消息被发送到下游时，下游链路的跃点计数（和线程跃点计数）被设置为比最大的传入链路跃点计数多一个。
Suppose a node N has some incoming links and an outgoing link, with hop counts all set properly, and N now acquires a new incoming link. If, and only if, the link hop count of the new incoming link is greater than that of all of the existing incoming links, the downstream link hop count must be changed. In this case, control messages must be sent downstream carrying the new, larger thread hop count.
假设一个节点N有一些传入链路和一个传出链路，并且跳数都设置正确，并且N现在获得了一个新的传入链路。如果且仅当新传入链路的链路跳数大于所有现有传入链路的跳数，则必须更改下游链路跳数。在这种情况下，必须向下游发送控制消息，其中包含新的、更大的线程跳数。
If, on the other hand, N acquires a new incoming link with a link hop count that is less than or equal to the link hop count of all existing incoming links, the downstream link hop count remains unchanged, and no messages need be sent downstream.
另一方面，如果N获取的新传入链路的链路跳数小于或等于所有现有传入链路的链路跳数，则下游链路跳数保持不变，并且不需要向下游发送消息。
Suppose N loses the incoming link whose hop count was the largest of any of the incoming links. In this case, the downstream link hop count must be made smaller, and messages need to be sent downstream to indicate this.
假设N丢失了一个传入链路，该链路的跳数是所有传入链路中最大的。在这种情况下，下游链路跳数必须更小，并且需要向下游发送消息来指示这一点。
Suppose we were not concerned with loop prevention, but only with the maintenance of the hop counts. Then we would adopt the following rules to be used by merge points:
假设我们不关心循环预防，而只关心跳数的维护。然后，合并点将采用以下规则：
A.3.1 When a new incoming thread is received, extend it downstream if and only if its hop count is the largest of all incoming threads.
A.3.1 当接收到新的传入线程时，仅当其跃点计数是所有传入线程中最大的时，才将其向下扩展。
A.3.2 Otherwise, rewind the thread.
A.3.2 否则，倒带线程。
A.3.3 An egress node would, of course, always rewind the thread.
A.3.3 当然，出口节点总是会倒带线程。
Nodes create new threads as a result of next hop changes or next hop acquisitions. Let's suppose that every time a thread is created by a node, the node assigns a unique "color" to it. This color is to be unique in both time and space: its encoding consists of an IP address of the node concatenated with a unique event identifier from a numbering space maintained by the node. The path setup messages that the node sends downstream will contain this color. Also, when the node sends such a message downstream, it will remember the color, and this color becomes the color of the downstream link.
节点创建新线程作为下一跳更改或下一跳获取的结果。假设每次节点创建线程时，节点都会为其指定唯一的“颜色”。此颜色在时间和空间上都是唯一的：其编码由节点的IP地址和节点维护的编号空间中的唯一事件标识符连接而成。节点向下游发送的路径设置消息将包含此颜色。此外，当节点向下游发送这样的消息时，它将记住颜色，并且该颜色将成为下游链接的颜色。
When a colored message is received, its color becomes the color of the incoming link. The thread which consists of messages of a certain color will be known as a thread of that color.
收到彩色消息时，其颜色将成为传入链接的颜色。由特定颜色的消息组成的线程称为该颜色的线程。
When a thread is rewound (and a path set up), the color is removed. The links become transparent, and we will sometimes speak of an established LSP as being a "transparent thread".
当重新缠绕线程（并设置路径）时，颜色将被删除。链接变得透明，我们有时会将已建立的LSP称为“透明线程”。
Note that packets cannot be forwarded on a colored link, but only on a transparent link.
请注意，数据包不能在彩色链路上转发，只能在透明链路上转发。
Note that if a thread loops, some node will see a message, over a particular incoming link, with a color that the node has already seen before. Either the node will have originated the thread of that color, or it will have a different incoming link which already has
请注意，如果线程循环，某些节点将通过特定的传入链接看到一条消息，该消息的颜色是该节点以前已经看到过的。该节点将创建该颜色的线程，或者它将具有一个已创建的不同传入链接
that color. This fact can be used to prevent control messages from looping. However, the node would be required to remember the colors of all the threads passing through it which have not been rewound or withdrawn. (I.e., it would have to remember a color for each path setup in progress.)
那颜色。这一事实可用于防止控制消息循环。但是，节点需要记住所有通过它的线程的颜色，这些线程没有被重新缠绕或抽出。（即，它必须记住正在进行的每个路径设置的颜色。）
By combining the color mechanism and the hop count mechanism, we can prevent loops without requiring any node to remember more than one color and one hop count per link for each LSP.
通过结合颜色机制和跳数机制，我们可以防止循环，而不需要任何节点为每个LSP记住多个颜色和每个链路一个跳数。
We have already stated that in order to maintain the hop counts, a node needs to extend only the thread which has the largest hop count of any incoming thread. Now we add the following rule:
我们已经说过，为了保持跳数，节点只需要扩展任何传入线程中跳数最大的线程。现在我们添加以下规则：
A.5.1 When extending an incoming thread downstream, that thread's color is also passed downstream (I.e., the downstream link's color will be the same as the color of the upstream link with largest hop count.)
A.5.1 将传入线程扩展到下游时，该线程的颜色也会传递到下游（即，下游链接的颜色将与跳数最大的上游链接的颜色相同）
Note that at a given node, the downstream link is either transparent or it has one and only one color.
请注意，在给定节点上，下游链接要么是透明的，要么只有一种颜色。
A.5.2 If a link changes color, there is no need to remember the old color.
A.5.2 如果链接更改了颜色，则无需记住旧颜色。
We now define the concept of "thread merging":
我们现在定义“线程合并”的概念：
A.5.2 Suppose a colored thread arrives at a node over an incoming link, the node already has an incoming thread with the same or larger hop count, and the node has an outgoing colored thread. In this case, we may say that the new incoming thread is "merged" into the outgoing thread.
A.5.2 假设一个有色线程通过传入链接到达一个节点，该节点已经有一个具有相同或更大跳数的传入线程，并且该节点有一个传出的有色线程。在这种情况下，我们可以说新的传入线程“合并”到传出线程中。
Note that when an incoming thread is merged into an outgoing thread, no messages are sent downstream.
请注意，当传入线程合并到传出线程时，不会向下游发送消息。
It can now be shown that if there is a loop, there will always either be some node which gets two incoming threads of the same color, or the colored thread will return to its initiator. In this section, we give several examples that may provide an intuitive understanding of how the thread loops are detected.
现在可以显示，如果有一个循环，那么总是会有某个节点获得两个相同颜色的传入线程，或者有色线程将返回到其启动器。在本节中，我们将给出几个示例，以直观地了解如何检测线程循环。
1 2
A---B---C K
| |
|3 |1
| |
| 4 5 | 6 7
D---G---H---I---J
|
|2
1 |
E---F
1 2
A---B---C K
| |
|3 |1
| |
| 4 5 | 6 7
D---G---H---I---J
|
|2
1 |
E---F
Returning to our previous example, let's set what would happen if H changed its next hop from I to E. H now creates a new thread, and assigns it a new color, say, red. Since H has two incoming link, with hop counts 1 and 5 respectively, it assigns hop count 6 to its new downstream link, and attempts a path setup through E.
回到上一个示例，让我们设置如果H将下一个跃点从I更改为E会发生什么。H现在创建一个新线程，并为其指定一个新颜色，例如红色。由于H有两个传入链路，其跳数分别为1和5，它将跳数6分配给其新的下游链路，并尝试通过E设置路径。
E now has an incoming red thread with hop count 6. Since E's downstream link hop count is now only 1, it must extend the red thread to F, with hop count 7. F then extends the red thread to D with hop count 8, D to G with hop count 9, and G to H with hop count 10.
E现在有一个传入的红色线程，跳数为6。由于E的下游链路跳数现在只有1，它必须将红色线程扩展到F，跳数为7。然后，F将红色线程扩展到具有跃点计数8的D，具有跃点计数9的D到G，以及具有跃点计数10的G到H。
The red thread has now returned to its initiator, and the loop is detected.
红色线程现在已返回到其启动器，并检测到循环。
Suppose though that before the red thread makes it back to H, G changes its next hop from H to E. Then G will extend the red thread to E. But E already has an incoming red link (from H), so the loop is detected.
假设在红色线程返回到H之前，G将其下一跳从H更改为E。然后G将红色线程扩展到E。但是E已经有一个传入的红色链接（来自H），因此循环被检测到。
Let's now define the notion of a "stalled thread". A stalled thread is a thread which is merged into the outgoing thread, even though the outgoing thread has a smaller link hop count.
现在让我们定义“暂停线程”的概念。暂停线程是合并到传出线程中的线程，即使传出线程的链接跃点计数较小。
When a thread loop is detected, the thread becomes stalled.
当检测到线程循环时，线程将停止。
A.6.1 When a loop is detected due to a thread of a particular color traversing some node twice, we will say that the thread is "stalled" at the node. More precisely, it is the second appearance of the thread which is stalled. Note that we say that a thread is traversing a node twice if the thread is received by that node on an incoming link, but either there is another incoming link with the same color, or the color is one that was assigned by the node itself.
A.6.1 当一个特定颜色的线程遍历某个节点两次而检测到一个循环时，我们会说该线程在该节点上“暂停”。更准确地说，这是线程的第二次出现。请注意，如果一个线程在传入链接上被一个节点接收到，那么我们说该线程将遍历一个节点两次，但要么存在另一个具有相同颜色的传入链接，要么该颜色是由节点本身指定的颜色。
The mechanism to be used for preventing the setup of looping LSPs should now be obvious. If node M is node N's next hop, and N wishes to set up an LSP (or to merge into an LSP which already exists at M), then N extends a thread to M.
用于防止设置循环LSP的机制现在应该是显而易见的。如果节点M是节点N的下一个跃点，并且N希望建立一个LSP（或者合并到已经存在于M的LSP中），那么N将一个线程扩展到M。
M first checks to see if the thread forms a loop (see Appendix A.6), and if so, the thread is stalled. If not, the following procedure is followed.
M首先检查线程是否形成循环（见附录a.6），如果是，则线程暂停。如果不是，则遵循以下步骤。
A.7.1 If M receives this thread, and M has a next hop, and either:
A.7.1 如果M接收到此线程，并且M有下一个跃点，并且：
- M has no outgoing thread
- M没有传出线程
- the incoming thread hop count is larger than the hop count of all other incoming threads,
- 传入线程跃点计数大于所有其他传入线程的跃点计数，
then M must extend the thread downstream.
然后M必须将螺纹延伸到下游。
A.7.2 On the other hand, if M receives this thread, and M has a next hop and there is another incoming thread with a larger hop count, then:
A.7.2 另一方面，如果M接收到此线程，并且M有下一个跃点，并且有另一个具有更大跃点计数的传入线程，则：
A.7.2.1 if the outgoing thread is transparent, M rewinds the new incoming thread.
A.7.2.1 如果传出线程是透明的，则M倒回新的传入线程。
A.7.2.2 if the outgoing thread is colored, M merges the new incoming thread into the outgoing thread, but does not send any messages downstream.
A.7.2.2 如果传出线程是彩色的，M将新的传入线程合并到传出线程中，但不向下游发送任何消息。
A.7.3 If M has not already assigned a label to N, it will assign one when, and only when, M rewinds the thread which N has extended to it.
A.7.3 如果M尚未为N分配标签，则仅当M倒回N已延伸到它的线程时，它才会为N分配一个标签。
A.7.4 If M merges the new thread into an existing colored outgoing thread, then the new incoming thread will rewind when, and only when, the outgoing thread rewinds.
A.7.4 如果M将新线程合并到现有的有色传出线程中，那么新传入线程将在传出线程倒带时（并且仅在传出线程倒带时）倒带。
A.8.1 If a particular node has a colored outgoing thread, and loses or changes its next hop, it withdraws the outgoing thread.
A.8.1 如果某个特定节点有一个彩色的传出线程，并且丢失或更改了它的下一个跃点，那么它将撤回传出线程。
Suppose that node N is immediately upstream of node M, and that N has extended a thread to M. Suppose further that N then withdraws the thread.
假设节点N紧靠节点M的上游，并且N已将线程扩展到M。进一步假设N随后退出该线程。
A.8.2 If M has another incoming thread with a larger hop count, then M does not send any messages downstream.
A.8.2 如果M有另一个具有较大跃点计数的传入线程，则M不会向下游发送任何消息。
A.8.3 However, if the withdrawn thread had the largest hop count of any incoming thread, then M's outgoing thread will no longer have the proper hop count and color. Therefore:
A.8.3 但是，如果退出的线程在任何传入线程中具有最大的跃点计数，那么M的传出线程将不再具有适当的跃点计数和颜色。因此：
A.8.3.1 M must now extend downstream the incoming thread with the largest hop count. (This will cause it to forget the old downstream link hop count and color.)
A.8.3.1 M现在必须以最大跳数向传入线程下游扩展。（这将导致它忘记旧的下游链路跳数和颜色。）
A.8.3.2 The other incoming threads are considered to be merged into the thread which is extended.
A.8.3.2 其他传入线程被视为合并到扩展的线程中。
A.8.4 When the last unstalled incoming thread is withdrawn, the outgoing thread must be withdrawn.
A.8.4 当退出最后一个未暂停的传入线程时，必须退出传出线程。
We have seen the way in which the withdrawal of a thread may cause hop count and color changes downstream. Note that if the hop count and/or color of an outgoing thread changes, then the hop count and color of the corresponding incoming thread at the next hop will also change. This may result in a color and/or next hop change of the outgoing thread at that next hop.
我们已经看到了线程的退出可能导致下游跳数和颜色变化的方式。请注意，如果传出线程的跃点计数和/或颜色发生变化，则下一跃点对应的传入线程的跃点计数和颜色也将发生变化。这可能会导致下一跳中传出线程的颜色和/或下一跳更改。
A.9.1 Whenever there is a hop count change for any incoming thread, a node must determine whether the "largest hop count of any incoming thread" has changed as a result. If so, the outgoing thread's hop count, and possibly color, will change as well, causing messages to be sent downstream.
A.9.1 每当任何传入线程的跃点计数发生变化时，节点必须确定“任何传入线程的最大跃点计数”是否因此发生了变化。如果是这样，传出线程的跃点计数（可能还有颜色）也会改变，从而导致消息被发送到下游。
A.10.1 If a particular node has a colored incoming thread, but has no next hop (or loses its next hop), the incoming thread is stalled.
A.10.1 如果某个特定节点有一个彩色的传入线程，但没有下一跳（或丢失下一跳），则传入线程将暂停。
It is possible that a node will experience a next hop change or a next hop acquisition at a time when it has colored incoming threads. This happens when routing changes before path setup is complete.
当一个节点有彩色的传入线程时，它可能会经历下一跳的更改或下一跳的获取。在路径设置完成之前更改路由时会发生这种情况。
A.11.1 If a node has a next hop change or a next hop acquisition at a time when it has colored incoming threads, it will create a thread with a new color, but whose hop count is one more than the largest of the incoming link hop counts. It will then extend this thread downstream.
A.11.1 如果节点在对传入线程着色时进行下一跳更改或下一跳获取，则它将创建具有新颜色的线程，但其跳数比传入链接跳数的最大值多一个。然后，它会将该线程延伸到下游。
A.11.2 When this new thread is created and extended downstream, all incoming threads are merged into it. Any incoming threads that were previously stalled are now considered to be "merged" rather than "stalled".
A.11.2 当这个新线程被创建并向下游扩展时，所有传入线程都会合并到其中。以前暂停的任何传入线程现在都被视为“合并”而不是“暂停”。
That is, even though the outgoing thread has a different color than any of the incoming threads, the pre-existing incoming threads are all considered to have been merged into the new outgoing thread. This means that when the outgoing thread rewinds, the incoming threads will too.
也就是说，即使传出线程的颜色与任何传入线程的颜色不同，也会认为预先存在的传入线程都已合并到新的传出线程中。这意味着当传出线程倒转时，传入线程也将倒转。
Note: it is still required to distinguish stalled incoming links from unstalled incoming links when thread withdrawing is performed.
注意：在执行线程退出时，仍然需要区分暂停的传入链接和未暂停的传入链接。
We have seen that when a loop is detected, the looping thread stalls. However, considering the following topology:
我们已经看到，当检测到循环时，循环线程会暂停。但是，考虑到以下拓扑结构：
X--->A----->B<---Y
^ |
| v
W--->D<-----C<---Z
X--->A----->B<---Y
^ |
| v
W--->D<-----C<---Z
In this example, there is a loop A-B-C-D-A. However, there are also threads entering the loop from X, Y, Z, and W. Once the loop is detected, there really is no reason why any other thread should have to wrap around the loop. It would be better to simply mark presence of the loop in each node.
在本例中，有一个循环a-B-C-D-a。但是，也有线程从X、Y、Z和W进入该循环。一旦检测到该循环，就没有任何其他线程必须环绕该循环的理由。最好只是在每个节点中标记循环的存在。
To do this, we introduce the notion of the "unknown" hop count, U. This hop count value is regarded as being larger than any other hop count value. A thread with hop count U will be known as a "U-thread".
为此，我们引入了“未知”跃点计数U的概念。该跃点计数值被视为大于任何其他跃点计数值。跳数为U的线程称为“U线程”。
A.12.1 When an incoming thread with a known hop count stalls, and there is an outgoing thread, we assign the hop count U to the outgoing thread, and we assign a new color to the outgoing thread as well.
A.12.1 当具有已知跃点计数的传入线程暂停，并且存在传出线程时，我们将跃点计数U分配给传出线程，并将新颜色分配给传出线程。
As a result, the next hop will then have an incoming U-thread, with the newly assigned color. This causes its outgoing thread in turn to be assigned hop count U and the new color. The rules we have already given will then cause each link in the loop to be assigned the new color and the hop count U. When this thread either reaches its originator, or any other node which already has an incoming thread of the same color, it stalls.
因此，下一个跃点将有一个新指定颜色的传入U线程。这将导致其传出线程依次被分配跃点计数U和新颜色。我们已经给出的规则将导致循环中的每个链接被分配新的颜色和跃点计数U。当该线程到达其发起者或任何其他已经有相同颜色的传入线程的节点时，它将暂停。
In our example above, this will cause the links AB, BC, CD, and DA to be given hop count U.
在上面的示例中，这将导致链路AB、BC、CD和DA被赋予跃点计数U。
Now let's add one more rule:
现在，让我们再添加一条规则：
A.12.2 When a thread with a known hop count reaches a node that has a colored outgoing U-thread, the incoming thread merges into the outgoing thread. (Actually, this is just a consequence of a rule which has already been given, since U is greater than any known hop count.)
A.12.2 当具有已知跃点计数的线程到达具有彩色传出U线程的节点时，传入线程合并到传出线程中。（实际上，这只是已经给出的规则的结果，因为U大于任何已知的跃点计数。）
Then if W, X, Y, or Z attempt to extend a thread to D, A, B, or C respectively, those threads will immediately stall. Once all the links are marked as being within a loop, no other threads are extended around the loop, i.e., no other setup messages will traverse the loop.
然后，如果W、X、Y或Z试图分别将线程扩展到D、a、B或C，这些线程将立即停止。一旦所有链接都标记为在一个循环内，就不会有其他线程围绕该循环扩展，也就是说，没有其他设置消息会遍历该循环。
Here is our example topology with the link hop counts that would exist during a loop:
下面是我们的示例拓扑，其中包含循环期间可能存在的链路跳数：
1 U 1
X--->A----->B<---Y
^ |
U | |U
| v
W--->D<-----C<---Z
1 U 1
1 U 1
X--->A----->B<---Y
^ |
U | |U
| v
W--->D<-----C<---Z
1 U 1
When a U-thread encounters a thread with known hop count, the usual rules apply, remembering that U is larger than any known hop count value.
当U线程遇到具有已知跃点计数的线程时，通常的规则适用，记住U大于任何已知跃点计数值。
However, we need to add a couple of special rules for the case when a U-thread encounters a U-thread. Since we can't tell which of the two U-threads is really the longer, we need to make sure that each of the U-threads is extended.
但是，我们需要为U线程遇到U线程的情况添加一些特殊规则。由于我们无法判断两个U线程中哪一个真正更长，因此我们需要确保每个U线程都已扩展。
A.13.1 If an incoming colored U-thread arrives at a node which already has an incoming U-thread of that color, or arrives at the node which created that U-thread, then the thread stalls.
A.13.1 如果传入的彩色U线程到达已经有该颜色传入U线程的节点，或到达创建该U线程的节点，则线程暂停。
(Once a loop is detected, there is no need to further extend the thread.)
（一旦检测到循环，就不需要进一步扩展线程。）
A.13.2 If an incoming colored U-thread arrives at a node which has a transparent outgoing U-thread to its next hop, the incoming thread is extended.
A.13.2 如果传入的彩色U线程到达具有透明传出U线程的节点，则传入线程将被扩展。
A.13.3 If an incoming colored U-thread arrives at a node which has a colored outgoing U-thread, and if the incoming link over which the thread was received was already an incoming link of the LSP, the thread is extended.
A.13.3 如果传入的彩色U线程到达具有彩色传出U线程的节点，并且如果接收该线程的传入链路已经是LSP的传入链路，则该线程将被扩展。
A.13.4 If an incoming colored U-thread arrives at a node which has a colored outgoing U-thread, and if the incoming link over which the thread was received was NOT already an incoming link of the LSP, a new U-thread is created and extended. All the incoming threads are merged into it. This is known in the main body of this document as "extending the thread with changing color".
A.13.4 如果传入的彩色U线程到达具有彩色传出U线程的节点，并且如果接收线程的传入链接不是LSP的传入链接，则会创建并扩展新的U线程。所有传入线程都合并到其中。这在本文档的主体部分称为“通过改变颜色扩展线程”。
These rules ensure that an incoming U-thread is always extended (or merged into a new U-thread which then gets extended), unless it is already known to form a loop.
这些规则确保传入的U线程总是被扩展（或合并到一个新的U线程中，然后被扩展），除非已经知道它会形成一个循环。
What is the purpose of rule A.13.4? There are certain cases where a loop can form, but where the node which created the looping thread is not part of the loop. Rule A.13.4 ensures that when there is a loop, there will be a looping thread which was created by some node which is actually in the loop. This in turn ensures that the loop will be detected well before the thread TTL expires.
规则A.13.4的目的是什么？在某些情况下，可以形成循环，但创建循环线程的节点不是循环的一部分。规则A.13.4确保当存在循环时，将有一个循环线程，该线程由实际在循环中的某个节点创建。这反过来又确保在线程TTL过期之前很好地检测到循环。
The rule of "extending the thread with changing color" is also applied when extending a thread with a known hop count.
当扩展具有已知跃点计数的线程时，也会应用“使用更改颜色扩展线程”规则。
A.13.5 When a received colored thread with a known hop count is extended, if the node has an outgoing thread, and if the incoming link over which the thread was received was NOT already an incoming link of the LSP, a new thread is created and extended. All the incoming threads are merged into it. This is an exceptional case of A.5.1.
A.13.5 当扩展具有已知跃点计数的已接收彩色线程时，如果节点具有传出线程，并且如果接收线程的传入链接不是LSP的传入链接，则会创建并扩展新线程。所有传入线程都合并到其中。这是A.5.1的例外情况。
Here is our example topology again, in the presence of a loop.
这里是我们的示例拓扑，在存在循环的情况下。
1 U 1
X--->A----->B<---Y
^ |
U | |U
| v
W--->D<-----C<---Z
1 U 1
1 U 1
X--->A----->B<---Y
^ |
U | |U
| v
W--->D<-----C<---Z
1 U 1
Suppose now that C's next hop changes from D to some other node E, thereby breaking the loop. For simplicity, we will assume that E is the egress node.
现在假设C的下一跳从D变为另一个节点E，从而中断循环。为简单起见，我们假设E是出口节点。
C will withdraw its outgoing U-thread from D (9.1). It will also create a new thread (12.1), assign it a new color, assign it hop count U (the largest hop count of C's incoming threads), merge its two other incoming threads into the new thread (12.2), and extend the new thread to E, resulting the following configuration:
C将从D（9.1）中取出其输出U形螺纹。它还将创建一个新线程（12.1），为其分配一个新颜色，为其分配跃点计数U（C传入线程的最大跃点计数），将其另外两个传入线程合并到新线程（12.2），并将新线程扩展到E，从而产生以下配置：
1 U 1
X--->A----->B<---Y
^ |
U | |U
| v
W--->D C<---Z
1 | 1
U|
v
E
1 U 1
X--->A----->B<---Y
^ |
U | |U
| v
W--->D C<---Z
1 | 1
U|
v
E
When the thread from C to E rewinds, the merged threads also rewind (8.4). This process of rewinding can now proceed all the way back to the leafs. While this is happening, of course, D will note that its outgoing thread hop count should be 2, not U, and will make this change (9.3). As a result, A will note that its outgoing hop count should be 3, not U, and will make this change. So at some time in the future, we might see the following:
当从C到E的线程倒带时，合并的线程也倒带（8.4）。这个倒带过程现在可以一直进行到叶子。当然，当这种情况发生时，D会注意到它的传出线程跃点计数应该是2，而不是U，并将进行此更改（9.3）。因此，a将注意到其传出跃点计数应为3，而不是U，并将进行此更改。因此，在未来某个时候，我们可能会看到以下情况：
1 3 1
X--->A----->B<---Y
^ |
2 | |U
| v
W--->D C<---Z
1 | 1
U|
v
E
1 3 1
X--->A----->B<---Y
^ |
2 | |U
| v
W--->D C<---Z
1 | 1
U|
v
E
After a short period, we see the following:
经过一段时间后，我们看到以下情况：
1 3 1
X--->A----->B<---Y
^ |
2 | |4
| v
W--->D C<---Z
1 | 1
5|
v
E
1 3 1
X--->A----->B<---Y
^ |
2 | |4
| v
W--->D C<---Z
1 | 1
5|
v
E
with all threads transparent, and we have a fully set up non-looping path.
所有线程都是透明的，我们有一个完全设置的非循环路径。
Nothing in the above requires that any node withdraw a transparent thread. Existing transparent threads (established paths) can continue to be used, even while new paths are being set up.
上面的任何内容都不要求任何节点提取透明线程。即使正在设置新路径，也可以继续使用现有的透明线程（已建立的路径）。
If this is done, then some node may have both a transparent outgoing thread (previous path) and a colored outgoing thread (new path being set up). This would happen only if the downstream links for the two threads are different. When the colored outgoing thread rewinds (and becomes transparent), the previous path should be withdrawn.
如果完成此操作，则某些节点可能同时具有透明传出线程（先前路径）和彩色传出线程（正在设置新路径）。只有当两个线程的下游链接不同时，才会发生这种情况。当彩色输出线程倒回（并变为透明）时，应退出上一条路径。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。