[要約] RFC 8570はIS-ISトラフィックエンジニアリング（TE）メトリック拡張に関するものであり、IS-ISプロトコルにおけるTEメトリックの拡張方法を提供しています。このRFCの目的は、ネットワークエンジニアがより効果的にトラフィックエンジニアリングを実施できるようにすることです。
Internet Engineering Task Force (IETF) L. Ginsberg, Ed.
Request for Comments: 8570 Cisco Systems, Inc.
Obsoletes: 7810 S. Previdi, Ed.
Category: Standards Track Huawei
ISSN: 2070-1721 S. Giacalone
Microsoft
D. Ward
Cisco Systems, Inc.
J. Drake
Juniper Networks
Q. Wu
Huawei
March 2019
IS-IS Traffic Engineering (TE) Metric Extensions
IS-ISトラフィックエンジニアリング（TE）メトリック拡張
Abstract
概要
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.
金融情報ネットワーク（株式市場データプロバイダーなど）などの特定のネットワークでは、ネットワークパフォーマンス基準（レイテンシなど）が他のメトリックと同様にデータパス選択にとって重要になってきています。
This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.
このドキュメントでは、IS-ISトラフィックエンジニアリング拡張機能（RFC 5305）の拡張機能について説明します。これらの拡張機能は、ネットワークパフォーマンス情報をスケーラブルな方法で配布および収集する方法を提供します。 IS-IS TEメトリック拡張を使用して配布された情報は、ネットワークパフォーマンスに基づいてパス選択を決定するために使用できます。
Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.
このドキュメントでは、ネットワークパフォーマンス情報が配信されるメカニズムのみを取り上げていることに注意してください。ネットワークのパフォーマンスを測定したり、その情報を処理したりするメカニズムは、一度配布されると、このドキュメントの範囲外です。
This document obsoletes RFC 7810.
このドキュメントはRFC 7810を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8570.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8570で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. TE Metric Extensions to IS-IS ...................................5
3. Interface and Neighbor Addresses ................................6
4. Sub-TLV Details .................................................7
4.1. Unidirectional Link Delay Sub-TLV ..........................7
4.2. Min/Max Unidirectional Link Delay Sub-TLV ..................8
4.3. Unidirectional Delay Variation Sub-TLV .....................9
4.4. Unidirectional Link Loss Sub-TLV ..........................10
4.5. Unidirectional Residual Bandwidth Sub-TLV .................11
4.6. Unidirectional Available Bandwidth Sub-TLV ................12
4.7. Unidirectional Utilized Bandwidth Sub-TLV .................13
5. Announcement Thresholds and Filters ............................13
6. Announcement Suppression .......................................14
7. Network Stability and Announcement Periodicity .................15
8. Enabling and Disabling Sub-TLVs ................................15
9. Static Metric Override .........................................15
10. Compatibility .................................................15
11. Security Considerations .......................................15
12. IANA Considerations ...........................................16
13. References ....................................................17
13.1. Normative References .....................................17
13.2. Informative References ...................................18
Appendix A. Changes from RFC 7810 .................................19
Acknowledgements ..................................................20
Contributors ......................................................20
Authors' Addresses ................................................21
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance information (e.g., latency) is becoming as critical to data-path selection as other metrics.
金融情報ネットワーク（株式市場データプロバイダーなど）などの特定のネットワークでは、ネットワークパフォーマンス情報（レイテンシなど）は、他のメトリックと同様にデータパス選択にとって重要になってきています。
In these networks, extremely large amounts of money rest on the ability to access market data in "real time" and to predictably make trades faster than the competition. Because of this, using metrics such as hop count or cost as routing metrics is becoming only tangentially important. Rather, it would be beneficial to be able to make path-selection decisions based on performance data (such as latency) in a cost-effective and scalable way.
これらのネットワークでは、「リアルタイム」で市場データにアクセスし、予想よりも早く取引を行う能力に、非常に多くのお金がかかっています。このため、ルーティングメトリックとしてホップカウントやコストなどのメトリックを使用することは、接線的に重要になるだけです。むしろ、コスト効率がよくスケーラブルな方法でパフォーマンスデータ（遅延など）に基づいてパス選択の決定を行うことができれば有益です。
This document describes extensions (hereafter called "IS-IS TE Metric Extensions") to the Extended IS Reachability TLV defined in [RFC5305]; these extensions can be used to distribute network-performance information (such as link delay, delay variation, packet loss, residual bandwidth, and available bandwidth).
このドキュメントでは、[RFC5305]で定義されているExtended IS Reachability TLVの拡張機能（以降、「IS-IS TEメトリック拡張機能」と呼びます）について説明します。これらの拡張機能を使用して、ネットワークパフォーマンス情報（リンク遅延、遅延変動、パケット損失、残りの帯域幅、使用可能な帯域幅など）を配布できます。
The data distributed by the IS-IS TE Metric Extensions described in this document is meant to be used as part of the operation of the routing protocol (e.g., by replacing cost with latency or considering bandwidth as well as cost), to enhance Constrained Shortest Path First (CSPF), or for other uses such as supplementing the data used by an Application-Layer Traffic Optimization (ALTO) server [RFC7285]. With respect to CSPF, the data distributed by IS-IS TE Metric Extensions can be used to set up, fail over, and fail back data paths using protocols such as RSVP-TE [RFC3209].
このドキュメントで説明されているIS-IS TEメトリック拡張によって配布されたデータは、ルーティングプロトコルの操作の一部として使用され（たとえば、コストをレイテンシで置き換えるか、帯域幅とコストを考慮することにより）、制約付き最短を強化しますパスファースト（CSPF）、またはその他の用途（アプリケーション層トラフィック最適化（ALTO）サーバー[RFC7285]で使用されるデータの補足など）。 CSPFに関しては、IS-IS TEメトリック拡張によって配布されたデータを使用して、RSVP-TE [RFC3209]などのプロトコルを使用するデータパスをセットアップ、フェイルオーバー、およびフェイルバックできます。
Note that the mechanisms described in this document only disseminate performance information. The methods for initially gathering that performance information (such as the methods described in [RFC6375]) or how to act on the information once it is distributed are outside the scope of this document. Example mechanisms to measure latency, delay variation, and loss in an MPLS network are given in [RFC6374]. While this document does not specify how the performance information should be obtained, the measurement of delay SHOULD NOT vary significantly based upon the offered traffic load. Thus, queuing delays SHOULD NOT be included in the delay measurement. For links such as forwarding adjacencies [RFC4206], care must be taken that measurement of the associated delay avoids significant queuing delays; that could be accomplished in a variety of ways, including either (1) measuring with a traffic class that experiences minimal queuing or (2) summing the measured link delays of the components of the link's path.
このドキュメントで説明するメカニズムは、パフォーマンス情報のみを配布することに注意してください。そのパフォーマンス情報を最初に収集する方法（[RFC6375]で説明されている方法など）または情報が配布された後の対処方法は、このドキュメントの範囲外です。 MPLSネットワークでの遅延、遅延変動、および損失を測定するメカニズムの例は、[RFC6374]で提供されています。このドキュメントでは、パフォーマンス情報を取得する方法を指定していませんが、遅延の測定値は、提供されたトラフィック負荷に基づいて大幅に変化してはなりません（SHOULD NOT）。したがって、キューイング遅延は遅延測定に含まれるべきではありません。転送隣接[RFC4206]などのリンクの場合、関連する遅延を測定することでキューイングによる重大な遅延が回避されるように注意する必要があります。これは、（1）最小のキューイングが発生するトラフィッククラスで測定する、または（2）リンクのパスのコンポーネントの測定されたリンク遅延を合計するなど、さまざまな方法で実現できます。
This document obsoletes [RFC7810].
このドキュメントは廃止されました[RFC7810]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document registers new IS-IS TE sub-TLVs in the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry. These new sub-TLVs provide ways to distribute network-performance information. The extensions in this document build on the extensions provided in IS-IS TE [RFC5305] and GMPLS [RFC4203].
このドキュメントでは、「TLV 22、23、141、222、および223のサブTLV」レジストリに新しいIS-IS TEサブTLVを登録しています。これらの新しいサブTLVは、ネットワークパフォーマンス情報を配信する方法を提供します。このドキュメントの拡張機能は、IS-IS TE [RFC5305]およびGMPLS [RFC4203]で提供される拡張機能に基づいています。
The Extended IS Reachability TLV (type 22) (defined in [RFC5305]), Inter-AS Reachability TLV (also called "inter-AS reachability information TLV") (type 141) (defined in [RFC5316]), and MT-ISN TLV (type 222) (defined in [RFC5120]) have nested sub-TLVs that permit the TLVs to be readily extended. This document registers several sub-TLVs:
拡張IS到達可能性TLV（タイプ22）（[RFC5305]で定義）、AS間到達可能性TLV（「AS間到達可能性情報TLV」とも呼ばれる）（タイプ141）（[RFC5316]で定義）、およびMT-ISN TLV（タイプ222）（[RFC5120]で定義）には、TLVを容易に拡張できるようにするネストされたサブTLVがあります。このドキュメントでは、いくつかのサブTLVを登録しています。
Type Description
----------------------------------------------------
33 Unidirectional Link Delay
34 Min/Max Unidirectional Link Delay
34最小/最大単方向リンク遅延
35 Unidirectional Delay Variation
35単方向遅延変動
36 Unidirectional Link Loss
36単方向リンク損失
37 Unidirectional Residual Bandwidth
37単方向残余帯域幅
38 Unidirectional Available Bandwidth
38単一方向の利用可能な帯域幅
39 Unidirectional Utilized Bandwidth
39単一方向利用帯域幅
As can be seen in the list above, the sub-TLVs described in this document carry different types of network-performance information. The new sub-TLVs include a bit called the Anomalous (or "A") bit. When the A bit is clear (or when the sub-TLV does not include an A bit), the sub-TLV describes steady-state link performance. This information could conceivably be used to construct a steady-state performance topology for initial tunnel-path computation or to verify alternative failover paths.
上記のリストからわかるように、このドキュメントで説明するサブTLVには、さまざまなタイプのネットワークパフォーマンス情報が含まれています。新しいサブTLVには、異常（または「A」）ビットと呼ばれるビットが含まれています。 Aビットがクリアされている場合（またはサブTLVにAビットが含まれていない場合）、サブTLVは定常状態のリンクパフォーマンスを示します。この情報は、初期のトンネルパス計算用の定常状態のパフォーマンストポロジを構築したり、別のフェイルオーバーパスを確認したりするために使用できます。
When network performance violates configurable link-local thresholds, a sub-TLV with the A bit set is advertised. That sub-TLV could be used by the receiving node to determine whether to (1) fail traffic to a backup path or (2) calculate an entirely new path. From an MPLS perspective, the intent of the A bit is to permit label switched path ingress nodes to determine whether the link referenced in the sub-TLV affects any of the label switched paths for which it is ingress. If they are affected, then they can determine whether those label switched paths still meet end-to-end performance objectives. If not, then the node could conceivably move affected traffic to a pre-established protection label switched path or establish a new label switched path and place the traffic in it.
ネットワークパフォーマンスが設定可能なリンクローカルしきい値に違反すると、Aビットが設定されたサブTLVがアドバタイズされます。受信ノードはそのサブTLVを使用して、（1）バックアップパスへのトラフィックを失敗させるか、（2）まったく新しいパスを計算するかを決定できます。 MPLSの観点から見ると、Aビットの目的は、ラベルスイッチドパスの入口ノードが、サブTLVで参照されるリンクが、それが入口であるラベルスイッチドパスのいずれかに影響を与えるかどうかを判断できるようにすることです。影響を受ける場合、それらのラベルスイッチドパスが引き続きエンドツーエンドのパフォーマンス目標を満たしているかどうかを判断できます。そうでない場合、ノードは、影響を受けるトラフィックを事前に確立された保護ラベルスイッチドパスに移動するか、新しいラベルスイッチドパスを確立してトラフィックをそこに配置することが考えられます。
If link performance then improves beyond a configurable minimum value (reuse threshold), that sub-TLV can be re-advertised with the A bit cleared. In this case, a receiving node can conceivably do whatever re-optimization (or failback) it wishes to do (including nothing).
リンクのパフォーマンスが構成可能な最小値（再利用のしきい値）を超えて向上した場合、そのサブTLVは、Aビットがクリアされた状態で再アドバタイズできます。この場合、受信側ノードは、何でもやり直したい（または何も含めない）再最適化（またはフェイルバック）を行うことができます。
Note that when a sub-TLV does not include the A bit, that sub-TLV cannot be used for failover purposes. The A bit was intentionally omitted from some sub-TLVs to help mitigate oscillations. See Section 5 for more information.
サブTLVにAビットが含まれていない場合、そのサブTLVはフェイルオーバーの目的で使用できないことに注意してください。発振を緩和するために、一部のサブTLVからAビットが意図的に省略されました。詳細については、セクション5を参照してください。
Consistent with the existing IS-IS TE specification [RFC5305], the bandwidth advertisements defined in this document MUST be encoded as IEEE floating-point values [IEEE754]. The delay and delay-variation advertisements defined in this document MUST be encoded as integer values. Delay values MUST be quantified in units of microseconds, packet loss MUST be quantified as a percentage of packets sent, and bandwidth MUST be sent as bytes per second. All values (except residual bandwidth) MUST be calculated as rolling averages, where the averaging period MUST be a configurable period of time. See Section 5 for more information.
既存のIS-IS TE仕様[RFC5305]に準拠して、このドキュメントで定義されている帯域幅通知は、IEEE浮動小数点値[IEEE754]としてエンコードする必要があります。このドキュメントで定義されているdelayおよびdelay-variation通知は、整数値としてエンコードする必要があります。遅延値はマイクロ秒単位で定量化する必要があり、パケット損失は送信するパケットの割合として定量化する必要があり、帯域幅はバイト/秒として送信する必要があります。すべての値（残余帯域幅を除く）はローリング平均として計算する必要があり、平均期間は構成可能な期間でなければなりません（MUST）。詳細については、セクション5を参照してください。
The use of IS-IS TE Metric Extensions sub-TLVs is not confined to the TE context. In other words, IS-IS TE Metric Extensions sub-TLVs defined in this document can also be used for computing paths in the absence of a TE subsystem.
IS-IS TEメトリック拡張サブTLVの使用は、TEコンテキストに限定されません。つまり、このドキュメントで定義されているIS-IS TEメトリック拡張サブTLVは、TEサブシステムがない場合のパスの計算にも使用できます。
However, as for the TE case, Interface Address and Neighbor Address sub-TLVs (IPv4 or IPv6) MUST be present. The encoding is defined in [RFC5305] for IPv4 and in [RFC6119] for IPv6.
ただし、TEの場合と同様に、インターフェイスアドレスとネイバーアドレスのサブTLV（IPv4またはIPv6）が存在する必要があります。エンコーディングは、IPv4の場合は[RFC5305]で、IPv6の場合は[RFC6119]で定義されています。
This sub-TLV advertises the average link delay between two directly connected IS-IS neighbors. The delay advertised by this sub-TLV MUST be the delay from the local neighbor to the remote neighbor (i.e., the forward-path latency). The format of this sub-TLV is shown in the following diagram:
このサブTLVは、直接接続された2つのIS-ISネイバー間の平均リンク遅延をアドバタイズします。このサブTLVによってアドバタイズされる遅延は、ローカルネイバーからリモートネイバーへの遅延（つまり、フォワードパスレイテンシ）でなければなりません（MUST）。このサブTLVのフォーマットを次の図に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
図1
where:
ただし：
Type: 33
タイプ：33
Length: 4
長さ：4
A bit: This field represents the Anomalous (A) bit. The A bit is set when the measured value of this parameter exceeds its configured maximum threshold. The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is cleared, the sub-TLV represents steady-state link performance.
ビット：このフィールドは、異常（A）ビットを表します。このパラメーターの測定値が構成された最大しきい値を超えると、Aビットが設定されます。 Aビットは、測定値が構成済みの再利用しきい値を下回るとクリアされます。 Aビットがクリアされている場合、サブTLVは定常状態のリンクパフォーマンスを表します。
RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.
予約済み：このフィールドは将来の使用のために予約されています。送信時には0に設定する必要があり、受信時には無視する必要があります。
Delay: This 24-bit field carries the average link delay over a configurable interval in microseconds, encoded as an integer value. When set to the maximum value 16,777,215 (16.777215 seconds), then the delay is at least that value and may be larger.
遅延：この24ビットのフィールドは、構成可能な間隔でのマイクロ秒単位の平均リンク遅延を整数値としてエンコードして伝達します。最大値16,777,215（16.777215秒）に設定すると、遅延は少なくともその値になり、大きくなる可能性があります。
This sub-TLV advertises the minimum and maximum delay values between two directly connected IS-IS neighbors. The delay advertised by this sub-TLV MUST be the delay from the local neighbor to the remote neighbor (i.e., the forward-path latency). The format of this sub-TLV is shown in the following diagram:
このサブTLVは、直接接続された2つのIS-ISネイバー間の最小および最大遅延値をアドバタイズします。このサブTLVによってアドバタイズされる遅延は、ローカルネイバーからリモートネイバーへの遅延（つまり、フォワードパスレイテンシ）でなければなりません（MUST）。このサブTLVのフォーマットを次の図に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Min Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Max Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
図2
where:
ただし：
Type: 34
タイプ：34
Length: 8
長さ：8
A bit: This field represents the Anomalous (A) bit. The A bit is set when one or more measured values exceed a configured maximum threshold. The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is cleared, the sub-TLV represents steady-state link performance.
ビット：このフィールドは、異常（A）ビットを表します。 1つ以上の測定値が構成された最大しきい値を超えると、Aビットが設定されます。 Aビットは、測定値が構成済みの再利用しきい値を下回るとクリアされます。 Aビットがクリアされている場合、サブTLVは定常状態のリンクパフォーマンスを表します。
RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.
予約済み：このフィールドは将来の使用のために予約されています。送信時には0に設定する必要があり、受信時には無視する必要があります。
Min Delay: This 24-bit field carries the minimum measured link delay value (in microseconds) over a configurable interval, encoded as an integer value.
最小遅延：この24ビットのフィールドは、構成可能な間隔で測定された最小のリンク遅延値（マイクロ秒単位）を整数値としてエンコードして保持します。
Max Delay: This 24-bit field carries the maximum measured link delay value (in microseconds) over a configurable interval, encoded as an integer value.
最大遅延：この24ビットのフィールドは、構成可能な間隔で測定された最大のリンク遅延値（マイクロ秒単位）を整数値としてエンコードして運びます。
Implementations MAY also permit the configuration of an offset value (in microseconds) to be added to the measured delay value, to facilitate the communication of operator-specific delay constraints.
実装はまた、オフセット値（マイクロ秒単位）の構成を測定された遅延値に追加して、オペレーター固有の遅延制約の通信を容易にすることを許可する場合があります。
It is possible for Min Delay and Max Delay to be the same value.
最小遅延と最大遅延が同じ値になる可能性があります。
When the delay value (Min Delay or Max Delay) is set to the maximum value 16,777,215 (16.777215 seconds), then the delay is at least that value and may be larger.
遅延値（最小遅延または最大遅延）が最大値16,777,215（16.777215秒）に設定されている場合、遅延は少なくともその値であり、大きくなる可能性があります。
This sub-TLV advertises the average link delay variation between two directly connected IS-IS neighbors. The delay variation advertised by this sub-TLV MUST be the delay from the local neighbor to the remote neighbor (i.e., the forward-path latency). The format of this sub-TLV is shown in the following diagram:
このサブTLVは、直接接続された2つのIS-ISネイバー間の平均リンク遅延変動をアドバタイズします。このサブTLVによってアドバタイズされる遅延変動は、ローカルネイバーからリモートネイバーへの遅延（つまり、フォワードパスレイテンシ）でなければなりません。このサブTLVのフォーマットを次の図に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
図3
where:
ただし：
Type: 35
タイプ：35
Length: 4
長さ：4
RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.
予約済み：このフィールドは将来の使用のために予約されています。送信時には0に設定する必要があり、受信時には無視する必要があります。
Delay Variation: This 24-bit field carries the average link delay variation over a configurable interval in microseconds, encoded as an integer value. When set to 0, it has not been measured. When set to the maximum value 16,777,215 (16.777215 seconds), then the delay is at least that value and may be larger.
遅延変動：この24ビットのフィールドは、構成可能な間隔での平均リンク遅延変動をマイクロ秒単位で伝達し、整数値としてエンコードします。 0に設定されている場合、測定されていません。最大値16,777,215（16.777215秒）に設定すると、遅延は少なくともその値になり、大きくなる可能性があります。
This sub-TLV advertises the loss (as a packet percentage) between two directly connected IS-IS neighbors. The link loss advertised by this sub-TLV MUST be the packet loss from the local neighbor to the remote neighbor (i.e., the forward-path loss). The format of this sub-TLV is shown in the following diagram:
このサブTLVは、直接接続された2つのIS-ISネイバー間の損失を（パケットの割合として）通知します。このサブTLVによってアドバタイズされるリンク損失は、ローカルネイバーからリモートネイバーへのパケット損失（つまり、転送パス損失）でなければなりません（MUST）。このサブTLVのフォーマットを次の図に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Link Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
図4
where:
ただし：
Type: 36
タイプ：36
Length: 4
長さ：4
A bit: This field represents the Anomalous (A) bit. The A bit is set when the measured value of this parameter exceeds its configured maximum threshold. The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is cleared, the sub-TLV represents steady-state link performance.
ビット：このフィールドは、異常（A）ビットを表します。このパラメーターの測定値が構成された最大しきい値を超えると、Aビットが設定されます。 Aビットは、測定値が構成済みの再利用しきい値を下回るとクリアされます。 Aビットがクリアされている場合、サブTLVは定常状態のリンクパフォーマンスを表します。
RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.
予約済み：このフィールドは将来の使用のために予約されています。送信時には0に設定する必要があり、受信時には無視する必要があります。
Link Loss: This 24-bit field carries link packet loss as a percentage of the total traffic sent over a configurable interval. The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. This value is the highest packet-loss percentage that can be expressed (the assumptions being that (1) precision is more important on high-speed links than the ability to advertise loss rates greater than this and (2) high-speed links with over 50% loss are unusable). Therefore, measured values that are larger than the field maximum SHOULD be encoded as the maximum value.
リンク損失：この24ビットのフィールドは、構成可能な間隔で送信されたトラフィック全体のパーセンテージとしてリンクパケット損失を伝達します。基本単位は0.000003％で、（2 ^ 24-2）は50.331642％です。この値は、表現できる最も高いパケット損失率です（この前提は、（1）精度がこれよりも高い損失率をアドバタイズする機能よりも高速リンクで重要であり、（2）高速リンクが50％の損失は使用できません）。したがって、フィールドの最大値より大きい測定値は、最大値としてエンコードする必要があります（SHOULD）。
This sub-TLV advertises the residual bandwidth between two directly connected IS-IS neighbors. The residual bandwidth advertised by this sub-TLV MUST be the residual bandwidth from the system originating the Link State Advertisement (LSA) to its neighbor.
このサブTLVは、直接接続された2つのIS-ISネイバー間の残りの帯域幅をアドバタイズします。このサブTLVによってアドバタイズされる残りの帯域幅は、リンク状態アドバタイズメント（LSA）を発信するシステムからそのネイバーへの残りの帯域幅である必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Residual Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
図5
where:
ただし：
Type: 37
タイプ：37
Length: 4
長さ：4
Residual Bandwidth: This field carries the residual bandwidth on a link, forwarding adjacency [RFC4206], or bundled link in IEEE floating-point format with units of bytes per second. For a link or forwarding adjacency, residual bandwidth is defined to be the maximum bandwidth [RFC5305] minus the bandwidth currently allocated to RSVP-TE label switched paths. For a bundled link, residual bandwidth is defined to be the sum of the component link residual bandwidths.
残余帯域幅：このフィールドは、リンク、転送隣接[RFC4206]、またはバンドルされたリンクの残余帯域幅を、1秒あたりのバイト数の単位を持つIEEE浮動小数点形式で伝達します。リンクまたは転送隣接の場合、残留帯域幅は、最大帯域幅[RFC5305]からRSVP-TEラベルスイッチドパスに現在割り当てられている帯域幅を引いたものとして定義されます。バンドルリンクの場合、残余帯域幅はコンポーネントリンクの残余帯域幅の合計として定義されます。
The calculation of residual bandwidth is different than that of unreserved bandwidth [RFC5305]. This calculation subtracts tunnel reservations from maximum bandwidth (i.e., the link capacity) [RFC5305] and provides an aggregated remainder across priorities. Unreserved bandwidth, on the other hand, is subtracted from the maximum reservable bandwidth (the bandwidth that can theoretically be reserved) and provides per-priority remainders. Residual bandwidth and unreserved bandwidth [RFC5305] can be used concurrently, and each has a separate use case (e.g., the former can be used for applications like Weighted ECMP, while the latter can be used for call admission control).
残余帯域幅の計算は、予約されていない帯域幅の計算とは異なります[RFC5305]。この計算は、最大帯域幅（つまり、リンク容量）[RFC5305]からトンネル予約を差し引いて、優先順位全体の残りの合計を提供します。一方、予約されていない帯域幅は、予約可能な最大帯域幅（理論的に予約できる帯域幅）から差し引かれ、優先度ごとの残りが提供されます。残りの帯域幅と予約されていない帯域幅[RFC5305]は同時に使用でき、それぞれ個別のユースケースがあります（たとえば、前者は加重ECMPなどのアプリケーションに使用でき、後者はコールアドミッション制御に使用できます）。
This sub-TLV advertises the available bandwidth between two directly connected IS-IS neighbors. The available bandwidth advertised by this sub-TLV MUST be the available bandwidth from the system originating this sub-TLV. The format of this sub-TLV is shown in the following diagram:
このサブTLVは、2つの直接接続されたIS-ISネイバー間で利用可能な帯域幅をアドバタイズします。このサブTLVによってアドバタイズされる利用可能な帯域幅は、このサブTLVを発信するシステムから利用可能な帯域幅である必要があります。このサブTLVのフォーマットを次の図に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
図6
where:
ただし：
Type: 38
タイプ：38
Length: 4
長さ：4
Available Bandwidth: This field carries the available bandwidth on a link, forwarding adjacency, or bundled link in IEEE floating-point format with units of bytes per second. For a link or forwarding adjacency, available bandwidth is defined to be residual bandwidth (see Section 4.5) minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths.
使用可能な帯域幅：このフィールドは、リンク、転送隣接、またはバンドルリンクで使用可能な帯域幅を、1秒あたりのバイト数の単位を持つIEEE浮動小数点形式で伝達します。リンクまたは転送隣接の場合、使用可能な帯域幅は、残余帯域幅（セクション4.5を参照）から非RSVP-TEラベルスイッチドパスパケットの実際の転送に使用される測定帯域幅を引いたものとして定義されます。バンドルリンクの場合、使用可能な帯域幅は、コンポーネントリンクの使用可能な帯域幅の合計として定義されます。
This sub-TLV advertises the bandwidth utilization between two directly connected IS-IS neighbors. The bandwidth utilization advertised by this sub-TLV MUST be the bandwidth from the system originating this sub-TLV. The format of this sub-TLV is shown in the following diagram:
このサブTLVは、直接接続された2つのIS-ISネイバー間の帯域幅使用率をアドバタイズします。このサブTLVによってアドバタイズされる帯域幅使用率は、このサブTLVを発信するシステムからの帯域幅である必要があります。このサブTLVのフォーマットを次の図に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Utilized Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
図7
where:
ただし：
Type: 39
タイプ：39
Length: 4
長さ：4
Utilized Bandwidth: This field carries the bandwidth utilization on a link, forwarding adjacency, or bundled link in IEEE floating-point format with units of bytes per second. For a link or forwarding adjacency, bandwidth utilization represents the actual utilization of the link (i.e., as measured by the advertising node). For a bundled link, bandwidth utilization is defined to be the sum of the component link bandwidth utilizations.
使用帯域幅：このフィールドは、リンク、転送隣接、またはバンドルされたリンクの帯域幅使用率を、1秒あたりのバイト数の単位を持つIEEE浮動小数点形式で伝達します。リンクまたは転送隣接の場合、帯域幅使用率はリンクの実際の使用率を表します（つまり、アドバタイジングノードによって測定されます）。バンドルリンクの場合、帯域幅使用率は、コンポーネントリンクの帯域幅使用率の合計として定義されます。
The values advertised in all sub-TLVs (except minimum/maximum delay and residual bandwidth) MUST represent an average over a period of time or be obtained by a filter that is reasonably representative of an average. For example, a rolling average is one such filter.
すべてのサブTLVでアドバタイズされる値（最小/最大遅延と残留帯域幅を除く）は、一定期間の平均を表すか、平均を合理的に表すフィルターによって取得する必要があります。たとえば、移動平均はそのようなフィルターの1つです。
Minimum and maximum delay MUST each be derived in one of the following ways: by taking the lowest and/or highest measured value over a measurement interval or by making use of a filter or other technique to obtain a reasonable representation of a minimum value and a maximum value representative of the interval, with compensation for outliers.
最小遅延と最大遅延はそれぞれ、次のいずれかの方法で導出する必要があります。測定間隔で最小または最大の測定値を取得するか、フィルターまたはその他の手法を利用して最小値と外れ値を補正した、間隔を表す最大値。
The measurement interval, any filter coefficients, and any advertisement intervals MUST be configurable per sub-TLV.
測定間隔、フィルター係数、およびアドバタイズメント間隔は、サブTLVごとに構成可能である必要があります。
In addition to the measurement intervals governing re-advertisement, implementations SHOULD provide configurable accelerated advertisement thresholds per sub-TLV, such that:
再アドバタイズを制御する測定間隔に加えて、実装では、サブTLVごとに次のような構成可能な加速アドバタイズしきい値を提供する必要があります（SHOULD）。
1. If the measured parameter falls outside a configured upper bound for all but the minimum delay metric (or lower bound for the minimum delay metric only) and the advertised sub-TLV is not already outside that bound, or
1. 測定されたパラメーターが、最小遅延メトリック以外のすべての構成済み上限（または最小遅延メトリックのみの下限）の外側にあり、アドバタイズされたサブTLVがまだその境界の外側にない場合、または
2. If the difference between the last advertised value and current measured value exceeds a configured threshold, then
2. 最後にアドバタイズされた値と現在の測定値の差が構成されたしきい値を超える場合、
3. The advertisement is made immediately.
3. 広告はすぐに作られます。
4. For sub-TLVs that include an A bit, an additional threshold SHOULD be included corresponding to the threshold for which the performance is considered anomalous (and sub-TLVs with the A bit are sent). The A bit is cleared when the sub-TLV's performance has been below (or re-crosses) this threshold for one or more advertisement intervals to permit failback.
4. Aビットを含むサブTLVの場合、パフォーマンスが異常と見なされるしきい値に対応する追加のしきい値を含める必要があります（およびAビットのサブTLVが送信されます）。サブTLVのパフォーマンスが1つ以上のアドバタイズメントインターバルでこのしきい値を下回る（または再クロスする）と、フェイルバックを許可するときに、Aビットはクリアされます。
To prevent oscillations, only the high threshold or the low threshold (but not both) may be used to trigger any given sub-TLV that supports both.
発振を防ぐために、高しきい値または低しきい値（両方ではない）のみを使用して、両方をサポートする特定のサブTLVをトリガーできます。
Additionally, once outside the bounds of the threshold, any re-advertisement of a measurement within the bounds would remain governed solely by the measurement interval for that sub-TLV.
さらに、しきい値の範囲外になると、範囲内の測定値の再アドバタイズは、そのサブTLVの測定間隔のみによって管理されたままになります。
When link-performance values change by small amounts that fall under thresholds that would cause the announcement of a sub-TLV, implementations SHOULD suppress sub-TLV re-advertisement and/or lengthen the period within which the sub-TLVs are refreshed.
リンクパフォーマンス値が、サブTLVのアナウンスを引き起こすしきい値を下回る少量で変化する場合、実装は、サブTLVの再アドバタイズメントを抑制するか、サブTLVが更新される期間を長くする必要があります。
Only the accelerated advertisement threshold mechanism described in Section 5 may shorten the re-advertisement interval. All suppression and re-advertisement interval backoff timer features SHOULD be configurable.
セクション5で説明されている加速されたアドバタイズメントしきい値メカニズムのみが、再アドバタイズメント間隔を短縮できます。すべての抑制および再アドバタイズメントインターバルのバックオフタイマー機能は設定可能である必要があります。
Sections 5 and 6 provide configurable mechanisms to bound the number of re-advertisements. Instability might occur in very large networks if measurement intervals are set low enough to overwhelm the processing of flooded information at some of the routers in the topology. Therefore, care should be taken in setting these values.
セクション5と6は、再アドバタイズメントの数を制限するための構成可能なメカニズムを提供します。トポロジー内の一部のルーターでフラッディングされた情報の処理を圧倒するほどに測定間隔を低く設定すると、非常に大規模なネットワークで不安定性が発生する可能性があります。したがって、これらの値の設定には注意が必要です。
Additionally, the default measurement interval for all sub-TLVs SHOULD be 30 seconds.
さらに、すべてのサブTLVのデフォルトの測定間隔は30秒である必要があります（SHOULD）。
Announcements MUST also be able to be throttled using configurable inter-update throttle timers. The minimum announcement periodicity is one announcement per second. The default value SHOULD be set to 120 seconds.
アナウンスは、構成可能な更新間スロットルタイマーを使用してスロットルできる必要もあります。アナウンスの最小周期は、毎秒1回のアナウンスです。デフォルト値は120秒に設定する必要があります（SHOULD）。
Implementations SHOULD NOT permit the inter-update timer to be lower than the measurement interval.
実装では、更新間隔を測定間隔よりも短くすることを許可しないでください。
Furthermore, it is RECOMMENDED that any underlying performance-measurement mechanisms not include any significant buffer delay, any significant buffer-induced delay variation, or any significant loss due to buffer overflow or due to active queue management.
さらに、基盤となるパフォーマンス測定メカニズムには、重大なバッファ遅延、重大なバッファ起因遅延の変動、またはバッファオーバーフローまたはアクティブなキュー管理による重大な損失が含まれないことをお勧めします。
Implementations MUST make it possible to individually enable or disable each sub-TLV based on configuration.
実装は、構成に基づいて各サブTLVを個別に有効または無効にできるようにする必要があります。
Implementations SHOULD permit static configuration and/or manual override of dynamic measurements for each sub-TLV in order to simplify migration and to mitigate scenarios where dynamic measurements are not possible.
実装は、移行を簡素化し、動的測定が不可能なシナリオを軽減するために、静的構成および/または各サブTLVの動的測定の手動オーバーライドを許可する必要があります。
As per [RFC5305], unrecognized sub-TLVs should be silently ignored.
[RFC5305]に従って、認識されないサブTLVは黙って無視されるべきです。
The sub-TLVs introduced in this document allow an operator to advertise state information of links (bandwidth, delay) that could be sensitive and that an operator may not want to disclose.
このドキュメントで紹介されているサブTLVを使用すると、機密性が高く、開示したくないリンクの状態情報（帯域幅、遅延）を広告することができます。
Section 7 describes a mechanism to ensure network stability when the new sub-TLVs defined in this document are advertised.
セクション7では、このドキュメントで定義されている新しいサブTLVがアドバタイズされるときに、ネットワークの安定性を確保するメカニズムについて説明します。
Implementations SHOULD follow the described guidelines to mitigate the risk of instability.
実装は、不安定性のリスクを軽減するために、説明されているガイドラインに従う必要があります。
[RFC5304] describes an authentication method for IS-IS Link State PDUs that allows cryptographic authentication of IS-IS Link State PDUs.
[RFC5304]では、IS-ISリンクステートPDUの暗号化認証を可能にするIS-ISリンクステートPDUの認証方法について説明しています。
It is anticipated that in most deployments, the IS-IS protocol is used within an infrastructure entirely under the control of the same operator. However, it is worth considering that the effect of sending IS-IS Traffic Engineering sub-TLVs over insecure links could include a man-in-the-middle attacker delaying real-time data to a given site or destination; this could negatively affect the value of the data for that site or destination. The use of Link State PDU cryptographic authentication allows mitigation of the risk of man-in-the-middle attacks.
ほとんどの展開では、IS-ISプロトコルがインフラストラクチャ内で完全に同じ事業者の制御下で使用されることが予想されます。ただし、安全でないリンクを介してIS-ISトラフィックエンジニアリングサブTLVを送信することの影響には、中間者攻撃がリアルタイムデータを特定のサイトまたは宛先に遅延させることが含まれる可能性があることを考慮する価値があります。これは、そのサイトまたは宛先のデータの価値に悪影響を及ぼす可能性があります。リンクステートPDU暗号化認証を使用すると、中間者攻撃のリスクを軽減できます。
IANA maintains the registry for the sub-TLVs. IANA has registered the following sub-TLVs in the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry:
IANAはサブTLVのレジストリを維持します。 IANAは、「TLV 22、23、141、222、および223のサブTLV」レジストリに次のサブTLVを登録しています。
Type Description
----------------------------------------------------
33 Unidirectional Link Delay
34 Min/Max Unidirectional Link Delay
34最小/最大単方向リンク遅延
35 Unidirectional Delay Variation
35単方向遅延変動
36 Unidirectional Link Loss
36単方向リンク損失
37 Unidirectional Residual Bandwidth
37単方向残余帯域幅
38 Unidirectional Available Bandwidth
38単一方向の利用可能な帯域幅
39 Unidirectional Utilized Bandwidth
39単一方向利用帯域幅
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2008.
[IEEE754] Institute of Electrical and Electronics Engineers、「IEEE Standard for Floating-Point Arithmetic」、IEEE Std 754-2008。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc4206>.
[RFC4206] Kompella、K。およびY. Rekhter、「Label Switched Paths（LSP）Hierarchy with Generalized Multi-Protocol Label Switching（GMPLS）Traffic Engineering（TE）」、RFC 4206、DOI 10.17487 / RFC4206、2005年10月、<https ：//www.rfc-editor.org/info/rfc4206>。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、DOI 10.17487 / RFC5120、 2008年2月、<https://www.rfc-editor.org/info/rfc5120>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<https://www.rfc-editor.org/info/rfc5304>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<https://www.rfc-editor.org/info/rfc5305> 。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[RFC5316] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするISIS拡張機能」、RFC 5316、DOI 10.17487 / RFC5316、2008年12月、< https://www.rfc-editor.org/info/rfc5316>。
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, <https://www.rfc-editor.org/info/rfc6119>.
[RFC6119] Harrison、J.、Berger、J。、およびM. Bartlett、「IS-ISでのIPv6トラフィックエンジニアリング」、RFC 6119、DOI 10.17487 / RFC6119、2011年2月、<https：//www.rfc-editor。 org / info / rfc6119>。
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.
[RFC7471] Giacalone、S.、Ward、D.、Drake、J.、Atlas、A。、およびS. Previdi、「OSPF Traffic Engineering（TE）Metric Extensions」、RFC 7471、DOI 10.17487 / RFC7471、2015年3月、 <https://www.rfc-editor.org/info/rfc7471>。
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, <https://www.rfc-editor.org/info/rfc7810>.
[RFC7810] Previdi、S.、Ed。、Giacalone、S.、Ward、D.、Drake、J.、and Q. Wu、 "IS-IS Traffic Engineering（TE）Metric Extensions"、RFC 7810、DOI 10.17487 / RFC7810、2016年5月、<https://www.rfc-editor.org/info/rfc7810>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K.、Ed。およびY. Rekhter編、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<https://www.rfc-editor.org/info / rfc4203>。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.
[RFC6374] Frost、D。およびS. Bryant、「MPLSネットワークのパケット損失と遅延測定」、RFC 6374、DOI 10.17487 / RFC6374、2011年9月、<https://www.rfc-editor.org/info/rfc6374 >。
[RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011, <https://www.rfc-editor.org/info/rfc6375>.
[RFC6375]フロスト、D、エド。およびS.ブライアント編、「MPLSベースのトランスポートネットワークのパケット損失と遅延測定プロファイル」、RFC 6375、DOI 10.17487 / RFC6375、2011年9月、<https://www.rfc-editor.org/info/ rfc6375>。
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <https://www.rfc-editor.org/info/rfc7285>.
[RFC7285]アリミ、R。、エド、ペンノ、R。、エド、ヤン、Y。、エド、キーゼル、S。、プレビディ、S。、ルーム、W。、シャルノフ、S.、R。 Woundy、「Application-Layer Traffic Optimization（ALTO）Protocol」、RFC 7285、DOI 10.17487 / RFC7285、2014年9月、<https://www.rfc-editor.org/info/rfc7285>。
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>.
[RFC8571] Ginsberg、L。、編、Previdi、S.、Wu、Q.、Tantsura、J。、およびC. Filsfils、「BGP-Link State（BGP-LS）Advertisement of IGP Traffic Engineering Performance Metric Extensions」 、RFC 8571、DOI 10.17487 / RFC8571、2019年3月、<https://www.rfc-editor.org/info/rfc8571>。
Errata ID 5293 (https://www.rfc-editor.org/errata/eid5293) correctly identified that in [RFC7810] the length associated with the following sub-TLVs did not match the figures associated with each:
エラータID 5293（https://www.rfc-editor.org/errata/eid5293）は、[RFC7810]で、次のサブTLVに関連付けられた長さがそれぞれに関連付けられた図と一致しないことを正しく識別しました：
37 Unidirectional Residual Bandwidth
37単方向残余帯域幅
38 Unidirectional Available Bandwidth
38単一方向の利用可能な帯域幅
39 Unidirectional Utilized Bandwidth
39単一方向利用帯域幅
The length specified was 4, which did not include the RESERVED field shown in the figures. Subsequent investigation revealed that some implementations had used the specified length (4) and omitted the RESERVED field while other implementations included the specified RESERVED field and used a length of 5.
指定された長さは4で、図に示されているRESERVEDフィールドは含まれていません。その後の調査により、一部の実装では指定された長さ（4）を使用してRESERVEDフィールドが省略されていることが判明しましたが、他の実装では指定されたRESERVEDフィールドが含まれ、長さ5が使用されました。
Because these different implementation choices are not interoperable, it was decided that a bis version should be generated to resolve this ambiguity.
これらの異なる実装の選択は相互運用性がないため、このあいまいさを解決するためにbisバージョンを生成することが決定されました。
The choice made here is to omit the unused RESERVED field from these sub-TLVs and use the length of 4. This matches the corresponding advertisements specified in the equivalent OSPF TE specification [RFC7471] and the corresponding BGP - Link State (BGP-LS) specification [RFC8571].
ここでの選択は、これらのサブTLVから未使用のRESERVEDフィールドを省略し、4の長さを使用することです。これは、同等のOSPF TE仕様[RFC7471]および対応するBGP-リンク状態（BGP-LS）で指定された対応するアドバタイズメントと一致します。仕様[RFC8571]。
Some minor editorial corrections have also been made.
いくつかのマイナーな編集上の修正も行われました。
Errata ID 5486 (https://www.rfc-editor.org/errata/eid5486) identified that in Section 4.6 of [RFC7810] the definition of available bandwidth on bundled links used a circular definition, i.e., it used "sum of the component link available bandwidths" when it should have used "sum of the component link residual bandwidths". This has been corrected and clarified.
Errata ID 5486（https://www.rfc-editor.org/errata/eid5486）は、[RFC7810]のセクション4.6で、バンドルされたリンクで利用可能な帯域幅の定義が循環定義を使用することを特定しました。 「コンポーネントリンクの使用可能な帯域幅」、「コンポーネントリンクの残りの帯域幅の合計」を使用する必要がある場合。これは修正および明確化されました。
Acknowledgements
謝辞
In [RFC7810], the authors recognized Ayman Soliman, Nabil Bitar, David McDysan, Edward Crabbe, Don Fedyk, Hannes Gredler, Uma Chunduri, Alvaro Retana, Brian Weis, and Barry Leiba for their contributions and reviews of this document.
[RFC7810]で、著者は、このドキュメントの寄稿とレビューについて、Ayman Soliman、Nabil Bitar、David McDysan、Edward Crabbe、Don Fedyk、Hannes Gredler、Uma Chunduri、Alvaro Retana、Brian Weis、およびBarry Leibaを認めました。
The authors also recognized Curtis Villamizar for significant comments and direct content collaboration.
著者はまた、重要なコメントと直接的なコンテンツのコラボレーションでCurtis Villamizarを認めました。
For this document, the authors thank Jeff Haas for identifying and reporting the incorrect encoding of the bandwidth-related sub-TLVs.
このドキュメントの作成者は、帯域幅関連のサブTLVの誤ったエンコーディングを特定して報告してくれたJeff Haasに感謝します。
Contributors
貢献者
The following people contributed substantially to the content of this document and should be considered coauthors:
次の人々はこのドキュメントの内容に実質的に貢献し、共著者と見なされるべきです：
Alia Atlas Juniper Networks United States of America Email: akatlas@juniper.net
Alia Atlas Juniper Networksアメリカ合衆国メール：akatlas@juniper.net
Clarence Filsfils Cisco Systems, Inc. Belgium Email: cfilsfil@cisco.com
Clarence Filsfils Cisco Systems、Inc.ベルギーEメール：cfilsfil@cisco.com
Authors' Addresses
著者のアドレス
Les Ginsberg (editor) Cisco Systems, Inc.
Les Ginsberg（編集者）Cisco Systems、Inc.
Email: ginsberg@cisco.com
Stefano Previdi (editor) Huawei
Stefano Previdi（編集者）Huawei
Email: stefano@previdi.net
Spencer Giacalone Microsoft
スペンサージャカロンマイクロソフト
Email: spencer.giacalone@gmail.com
Dave Ward Cisco Systems, Inc.
Dave Ward Cisco Systems、Inc.
Email: wardd@cisco.com
John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America
ジョンドレイクジュニパーネットワークス1194 N.マチルダアベニューサニーベール、カリフォルニア州94089アメリカ合衆国
Email: jdrake@juniper.net
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Wuhu AのQは101ソフトウェアアベニューで、Y Uは地区210012中国江蘇省NaN京を描画します
Email: bill.wu@huawei.com