[要約] RFC 3063は、MPLSネットワークでのループ防止メカニズムについての標準化ドキュメントです。その目的は、MPLSネットワーク内でのループの発生を防ぎ、ネットワークの安定性と信頼性を向上させることです。
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.
Copyright（c）The Internet Society（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マージと互換性がありますが、必要ありません。このメカニズムは、順序付けられた下流の需要の割り当てまたは順序付けられたダウンストリーム割り当てのいずれかで使用できます。プロトコルメッセージに渡す必要がある情報の量は、密接に境界が付けられています（つまり、パスベクトルは使用されません）。ノードが次のホップを変更する必要がある場合、分散手順が実行されますが、変更の下流のノードのみが関与します。
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
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]の新しい次のホップがあることを発見すると、スレッドを作成し、下流に拡張します。そのようなスレッドにはそれぞれ一意の「色」が割り当てられているため、ネットワーク内の2つのスレッドが同じ色を持つことはできません。
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をサポートする場合、一部、すべて、またはまったくない場合に機能します。また、順序付けられた下流のオンデマンドラベル割り当てのいずれか、または下流の未承諾ラベル割り当て[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が1つしかないかのように話します。これにより、「同じ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には1つ以上の着信リンクまたは上流のリンクがあり、1つの発信リンクまたは下流のリンクがあります。「リンク」は、「隣接する」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
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.
Node 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.
Node 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:
スレッドに関連する3つの属性があります。次のように、単一のスレッドオブジェクトにエンコードされる場合があります。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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.
一意の色割り当ての可能な方法の1つは、イベント識別子を初期値から起動し、色が割り当てられるたびに1つ（Moduloの最大値）で増分することです。この方法では、初期イベント識別子は、ランダムに選択されるか、以前のシステムの化身で使用された最大のイベント識別子よりも大きくなるように割り当てられます。
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.
他のどの既知の値よりも大きい特別なホップカウント値「不明」（= 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ループを防ぐために、5つの原始的なアクションが定義されます。このセクションでは、各原始的なアクションのみについて説明し、これらの原始的なアクションがどのように組み合わされているか、およびアルゴリズムがどのように機能するかについては説明していません。アルゴリズムの本体については、セクション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）色を変更せずにスレッドを伸ばします。受信したスレッドは、新しい着信リンクで受信され、既存の発信リンクで拡張された場合、色の変化で拡張されます。そうしないと、色を変更せずに拡張されます。色が変化するスレッドが拡張されると、新しい色のスレッドが作成され、拡張されます。
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の発信リンクホップカウントは少なくとも1つあります。新しく受信したスレッドのホップカウント。
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 色付きのスレッドは、出口ノードによって受信されます。または次のすべての条件が保持されます。（a）色のスレッドはノードnによって受信され、（b）nの発信リンクは透明であり、（c）Nの発信リンクホップカウント新しく受信されたスレッドのホップカウントより少なくとも1つは大きいです。
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は以前よりも1つの着信リンクが1つあります。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）発信リンクは透明です。ホップカウント。
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を再びリンクI1で不明なホップカウントの赤いスレッドを受け取ります（図3（b））。I1と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があります。次に、ホップカウント3の赤い糸が新しい着信リンクI2で受信されます。この場合、受信されたスレッドは色の変化で拡張されます。つまり、O1がすでに存在するため、新しい緑のスレッドが作成され、拡張されます（図4（b））。
(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の赤いスレッドを受信すると、発信リンクホップカウントが受信されたスレッドホップカウントより少なくとも1つ大きいため、受信されたスレッドは拡張されません。発信リンクO1の青い糸が巻き戻されると、赤と青の両方の糸が巻き戻されます。
(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は、糸の失速の例を示しています。図6の着信リンクI2でノードBがホップカウント10の青いスレッドを受信すると、青いスレッドがループを形成するため、受信されたスレッドが「失速」します。図7では、リーフノードAが独自のスレッドのループを見つけます。
(bl,3) (bl,4)
----[i1]--->B----[o1]--->
^
|
----{i2}----+
(bl,10)+
Fig.6 Thread stalling (1)
図6スレッドストール（1）
(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)
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に減少し、図9（b）に示すように、ノードBは新しい緑のスレッドを作成し、下流に拡張します。
(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)-
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の透明なスレッドが撤回されます。この場合、HMAXが減少し、発信リンクが透明であるため、透明なスレッドが拡張されます（図11（b））。
(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.
アルゴリズムでは、次のホップ変更イベントが2つのイベントに分けられます。古い次のホップでの次のホップ損失イベントと、この順序で新しい次のホップでの次のホップ取得イベントです。
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よりも1つ以上大きい場合、ホップカウントの透明なスレッド（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に対して2つの異なるLSPをセットアップすることにより、ロード分割を簡単に実行できます。2つのLSPのダウンストリームリンクには、単に異なる色が割り当てられます。スレッドアルゴリズムは、いずれかのパスでのループを防止するようになりましたが、2つのパスが共通のダウンストリームノードを持つこともできます。
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 Next Hopsがある場合、その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はそれぞれ、発信リンクに異なる色を使用します。スレッドアルゴリズムは、パスのいずれかのループを防止するようになりましたが、2つ以上のパスが共通のダウンストリームノードを持つこともできます。
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には2つの着信リンク、I1とI2と2つの発信リンク、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を2回横断する単一のループフリーLSPが確立されます。
+------------------...--------------------+
. (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はパケットごとに転送決定を下す機能を持っていないため、ATM-LSRがこのように分割をロードできないという事実が残っています。
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を通過するループがあるように、LSRS <r1、...、rn>のシーケンスを考えます。（つまり、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でなければならないことを保証します。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.
スレッドホップカウントが既知か不明かに関係なく、ループがある場合、ループ内の一部のノードは、新しい着信リンク上のスレッドを受信する最後のノードになります。このスレッドは、色が変わらずに常にそのノードに戻ってきます。したがって、ループは常にループ内のノードの少なくとも1つによって常に検出されます。
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.
同じ色のスレッドを2回2回拡張するノードはないため、実際に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.
第二に、「色が変化するスレッド」は、2つのスレッドが互いに追いかけるのを防ぎます。
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
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の緑のスレッドを拡張し始めます。カウント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.
少なくとも1つのケースがあります。「色が変化する」メカニズムは処理できません。つまり、同じスレッドがループで互いに追い出されるスレッドとスレッドが引き出す「セルフチェイシング」です。このケースは、ノードがスレッドを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.
このセクションでは、2つの例を示して、アルゴリズムが特定のネットワークで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.
L3ループが存在する図14に示すMPLSネットワークを考えてみましょう。各指示リンクは、各ノードのFECの現在の次のホップを表します。葉のノードR1とR6は、LSPの作成を開始します。
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、1,255）と（BL、1,255）が含まれています。
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).
R6から発信されるリクエストを受信する前に、R3がR1から発信されたリクエストを受信すると仮定します。R3が赤いスレッドで最初のリクエストを受信すると、R3は、受信リンクと発信リンクの両方が新しく作成されているため、スレッド色を変更せずに（RE、3,253）で転送します。次に、R3は青いスレッドで2番目の要求を受け取ります。この間、発信リンクはすでに存在しています。したがって、R3は色の変化で拡張されたスレッドを実行します。つまり、新しい茶色の糸を作成し、リクエストを（BR、4,255）で転送します。
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、6,250）でリクエストを受信すると、赤い糸がループを形成し、赤い糸が失速することがわかります。次に、R2は不明なホップカウントの紫色の糸を作成し、（PU、U、255）を使用してリクエストをR3に送信して下流に拡張します。ここで、「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、7,252）から別の要求を受け取ります。茶色の糸が紫色の糸に統合されます。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)
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にパス断downメッセージを送信します。次に、不明のホップカウントの緑のスレッドを作成し、（gr、u、255）を使用してR11にリクエストを送信します。
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)
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、1,255）で更新メッセージを送信して拡張します。
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、1,255）を作成し、下流に拡張します。
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)
Fig.17 The final network state
図17最終ネットワーク状態
+----- 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があり、次のホップがR3からR3からR6に変化すると仮定します。R2は、赤い糸でR6にリクエストを送信します（RE、2,255）。（RE、4,253）のリクエストがR4に達すると、色が変化するとスレッドがR5に拡張されます。したがって、R4で新しいグリーンスレッドが作成され、（GR、5,255）で更新メッセージを送信することにより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が断downメッセージを受信した場合、hmaxが変更されないため、R5に更新を送信しません。現在、確立された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は、青いスレッド（BL、2,255）を使用したリクエストをR3に送信します。R3は、リクエストを（BL、3,254）でR4に転送します。
When R4 receives the request, it immediately returns a label mapping message to R3 since Hmax does not change.
R4がリクエストを受信すると、HMAXが変更されないため、ラベルマッピングメッセージをR3にすぐに返します。
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に到達し、HMAXが4から3に減少するため、透明なスレッド（TR、4,255）を使用して更新メッセージをトリガーします。R5は、ACKを返すことなく着信リンクホップを4に更新します。
A thread control block (TCB) is maintained per LSP at each node and may contain the following information:
各ノードのLSPごとにスレッドコントロールブロック（TCB）が維持され、次の情報が含まれている場合があります。
- 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 -STATE-着信リンク各着信リンクには次の属性があります：oネイバー：上流の近隣ノードアドレスo色o色：受信スレッドホップカウントoラベルoラベルoラベルo s -flag：停止リンクを示します - それぞれそれぞれ発信リンク発信リンクには次の属性があります。Oネイバー：ダウンストリームネイバーノードアドレスo色o色：受信スレッドカラーOホップカウント：受信スレッドホップoラベルo c-flag：現在の次のホップへのリンクを示します
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スレッド」イベント内のイベントスイッチに使用されるフラグに続くフラグ（セクション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 Color Flag（CL-Flag）：受信されたスレッドが色付けされている場合は設定します。oループフラグ（LP-Flag）：受信されたスレッドがループを形成する場合は設定します。o新しいリンクフラグ（NL-FLAG）に到着：受信されたスレッドが新しい着信リンクに到着した場合に設定します。
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-FLAGが設定されている場合、受信リンクと同じスレッド色を保存する受信リンク以外に、着信リンクLが必要です。Link Lが属するTCBは、「TCBの検出」と呼ばれます。受信LSRがVCマージ対応の場合、検出TCBと受信TCBは同じです。そうでなければ、2つの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 =不明の場合、（hmax 1）の値は不明なホップカウントプラス1の値になります。たとえば、hmax = nokning = 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には3つの状態があります。ヌル、色付き、透明。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を使用すると、古い次のホップに1つの透明な発信リンクと、現在の次のホップに1つの色の発信リンクがあります。ただし、古いNext Hopに色付きの発信リンクがあることは許可されていません。
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 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 <不明の場合、色なしの変更スレッドを作成して拡張します。そうでなければ、何もしません。1 0 * hmax <houtの場合、受信されたスレッドをマージします。それ以外の変更はありません。スレッドを（nl = 1の場合）、または色を変更しない場合（nl = 0の場合）拡張します。1 1 *受信したスレッドを失速させます。ni = 0でノードが適格な葉でない場合、nullはスレッドの撤回を開始します。Ni> 0およびHREC <不明の場合、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、colored threadを変更して拡張します。そうでなければ、何もしません。変化なし
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.
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.
東芝および/またはシスコは、この文書で明らかにされたいくつかの技術について、特許またはその他の知的財産保護を求めることができます。この文書から発生する基準が、東芝および/またはシスコに割り当てられた1つ以上の特許によって保護されている場合、またはCiscoはそれらの特許を開示し、合理的かつ非差別的な条件でライセンスを取得する予定です。
We would like to thank Hiroshi Esaki, Bob Thomas, Eric Gray, and Joel Halpern for their comments.
Esaki Hiroshi、Bob Thomas、Eric Gray、Joel Halpernのコメントに感謝します。
Yoshihiro Ohba Toshiba Corporation 1, Komukai-Toshiba-cho, Saiwai-ku Kawasaki 210-8582, Japan
ヨシヒロ・オバ・トーバ・コーポレーション1、コムカイ・トーバヒバチョ、佐藤川川崎210-8582、日本
EMail: yoshihiro.ohba@toshiba.co.jp
Yasuhiro Katsube Toshiba Corporation 1, Toshiba-cho, Fuchu-shi, Tokyo, 183-8511, Japan
Yasuhiro Katsube Toshiba Corporation 1、Toshiba-Cho、Fuchu-Shi、Tokyo、183-8511、日本
EMail: yasuhiro.katsube@toshiba.co.jp
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Eric Rosen Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA、01824
EMail: erosen@cisco.com
Paul Doolan Ennovate Networks 330 Codman Hill Rd Marlborough MA 01719
Paul Doolan Enovate Networks 330 Codman Hill Rd Marlborough MA 01719
EMail: pdoolan@ennovatenetworks.com
[1] Callon, R., et al., "A Framework for Multiprotocol Label Switching", Work in Progress.
[1] Callon、R.、et al。、「マルチプロトコルラベルスイッチングのフレームワーク」、進行中の作業。
[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 Switchingを使用したMPLS」、RFC 3035、2001年1月。
[3] Rosen, E., et al., "A Proposed Architecture for MPLS", Work in Progress.
[3] Rosen、E.、et al。、「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。and 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が1つしかないかのように話します。そうでなければ、私たちはいつも「...同じ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.
たとえば、既存のLSP B-C-D-EがNode Eを出力することを検討してください。NodeNodeA LSPに参加しようとします。このアルゴリズムでは、aはb、bにc、cからcからd、dにメッセージをEからEに送信する必要があります。その後、メッセージはeからbからbからaに送信されます。パスがループフリーであることを知って、LSPに参加できます。
Using our terminology, we say that A created a thread and extended it downstream. The thread reached the egress, and then rewound.
用語を使用して、スレッドを作成し、下流に拡張したと言います。スレッドは出口に到達し、次に巻き戻しました。
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 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.
ループスレッドのこの状況からどのように回復しますか？L3ルーティングがループを破るためには、ループ内の一部のノードが次のホップ変更を経験する必要があります。このノードは、古い次のホップからスレッドを引き出し、新しい次のホップにスレッドを延長します。ループがなくなった場合、このスレッドは出口に到達し、巻き戻します。
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は両方のパスセットアップ試行の両方で状態を維持する必要があります。スレッドとc-thread。一般に、確立されたパスに参加しようとしている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マージが使用されていない場合、これは実際にはそれほど悪くはありません。VCマージがなければ、Dはとにかく各アップストリームノードに1つのLSPをサポートする必要があります。ただし、VCマージが使用されている場合、LSPをサポートするには、アップストリームリンクごとに1つの保持状態のみが必要です。ループ予防技術が、ノードによって保持されている状態の量が、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.
別の問題は、ループがある場合、セットアップメッセージがループを続けることです。スレッドがいくつかのノードを2回横断しているにもかかわらず、ノードには、現在受信しているセットアップメッセージが過去に受信したセットアップメッセージと同じスレッドの一部であることを伝える方法はありません。
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.
これらの2つの問題を排除するために、このブルートフォーススキームを変更できますか？我々はできる。これを行う方法を示すために、2つの概念を紹介します：スレッドホップカウントとスレッドカラー。
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
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には、これらのリンクから1つのホップアップストリームを1つだけ移動できるため、1つのラベルが付いています。リンク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.
パスセットアップメッセージが下流に送信されると、ダウンストリームリンクのホップカウント（およびスレッドホップカウント）は、着信リンクホップカウントの最大の1つ以上に設定されます。
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.
ホップカウントが着信リンクの中で最大の着信リンクを失うとします。この場合、ダウンストリームリンクホップカウントを小さくする必要があり、これを示すためにメッセージを下流に送信する必要があります。
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のリンクごとに複数の色と1つのホップカウントを記憶するためにノードを必要とせずにループを防ぐことができます。
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.
特定のノードでは、ダウンストリームリンクは透明であるか、1色のみが1色であることに注意してください。
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.
ループがある場合、同じ色の2つの着信スレッドを取得するノードが常にあるか、色付きのスレッドがイニシエーターに戻ることが常に表示されることが示されます。このセクションでは、スレッドループがどのように検出されるかについての直感的な理解を提供する可能性のあるいくつかの例を示します。
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からEからEに次のホップを変更した場合に何が起こるかを設定しましょう。Hは新しいスレッドを作成し、新しい色、たとえば赤を割り当てます。Hには2つの着信リンクがあり、ホップカウント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からg。
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 特定の色のスレッドがいくつかのノードを2回横断するためにループが検出されると、スレッドがノードで「失速」されていると言えます。より正確には、それは停止されたスレッドの2番目の外観です。スレッドがそのノードが着信リンクで受信された場合、スレッドはノードを2回通過しているが、同じ色の別の着信リンクがあるか、色はノード自体によって割り当てられたものです。
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にラベルを割り当てていない場合、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がさらに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 ノードが次のホップの変更または次のホップ取得が着信されたスレッドを着用している場合、新しい色のスレッドを作成しますが、ホップカウントは、着信リンクホップカウントの最大よりも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
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-thread」として知られています。
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:
次に、もう1つのルールを追加しましょう。
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-Threadの色が付いたノードに到達すると、着信スレッドが発信スレッドにマージされます。（実際、これは既知のホップ数よりも大きいため、すでに与えられたルールの結果にすぎません。）
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
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-Threadが既知のホップカウントでスレッドに遭遇すると、通常のルールが適用され、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-ThreadがUスレッドに遭遇した場合、ケースにいくつかの特別なルールを追加する必要があります。2つの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-Threadが到着すると、着信スレッドが拡張されます。
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
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-threadを撤回します。また、新しいスレッド（12.1）を作成し、新しい色を割り当て、ホップカウントU（Cの着信スレッドの最大ホップカウント）を割り当て、他の2つの着信スレッドを新しいスレッド（12.2）にマージし、拡張します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はその発信スレッドホップカウントがuではなく2でなければならず、この変更を行うことに注意してください（9.3）。その結果、発信ホップカウントはuではなく3である必要があり、この変更を行うことに注意してください。したがって、将来のある時点で、次のことを見るかもしれません。
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
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.
これが行われた場合、一部のノードには、透明な発信スレッド（前のパス）と色付きの発信スレッド（新しいパスが設定されている）の両方がある場合があります。これは、2つのスレッドのダウンストリームリンクが異なる場合にのみ発生します。色付きの発信スレッドが巻き戻す（そして透明になる）場合、前のパスは撤回する必要があります。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。