[要約] RFC 7810はIS-ISプロトコルのトラフィックエンジニアリング（TE）メトリック拡張に関するものであり、IS-ISネットワークでの経路選択におけるメトリックの拡張を提供します。目的は、ネットワークのトラフィックエンジニアリングを向上させ、効率的な経路選択を可能にすることです。
Internet Engineering Task Force (IETF) S. Previdi, Ed.
Request for Comments: 7810 Cisco Systems, Inc.
Category: Standards Track S. Giacalone
ISSN: 2070-1721 Microsoft
D. Ward
Cisco Systems, Inc.
J. Drake
Juniper Networks
Q. Wu
Huawei
May 2016
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) such that network-performance information can be distributed and collected 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.
このドキュメントでは、ネットワークパフォーマンス情報が配信されるメカニズムのみを取り上げていることに注意してください。ネットワークのパフォーマンスを測定したり、その情報を処理したりするメカニズムは、一度配布されると、このドキュメントの範囲外です。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7810.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7810で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. TE Metric Extensions to IS-IS . . . . . . . . . . . . . . . . 4
3. Interface and Neighbor Addresses . . . . . . . . . . . . . . 5
4. Sub-TLV Details . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Unidirectional Link Delay Sub-TLV . . . . . . . . . . . . 6
4.2. Min/Max Unidirectional Link Delay Sub-TLV . . . . . . . . 7
4.3. Unidirectional Delay Variation Sub-TLV . . . . . . . . . 8
4.4. Unidirectional Link Loss Sub-TLV . . . . . . . . . . . . 9
4.5. Unidirectional Residual Bandwidth Sub-TLV . . . . . . . . 10
4.6. Unidirectional Available Bandwidth Sub-TLV . . . . . . . 11
4.7. Unidirectional Utilized Bandwidth Sub-TLV . . . . . . . . 12
5. Announcement Thresholds and Filters . . . . . . . . . . . . . 12
6. Announcement Suppression . . . . . . . . . . . . . . . . . . 13
7. Network Stability and Announcement Periodicity . . . . . . . 14
8. Enabling and Disabling Sub-TLVs . . . . . . . . . . . . . . . 14
9. Static Metric Override . . . . . . . . . . . . . . . . . . . 14
10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 IS-IS Extended Reachability TLV defined in [RFC5305], that can be used to distribute network-performance information (such as link delay, delay variation, packet loss, residual bandwidth, and available bandwidth).
このドキュメントでは、[RFC5305]で定義されているIS-IS拡張到達可能性TLVの拡張機能（以降、「IS-IS TEメトリック拡張機能」）について説明します。これは、ネットワークパフォーマンス情報（リンク遅延、遅延変動、パケットなど）を配布するために使用できます。損失、残りの帯域幅、および利用可能な帯域幅）。
The data distributed by the IS-IS TE Metric Extensions proposed 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-SPF (CSPF), or for other uses such as supplementing the data used by an 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メトリック拡張によって配布されるデータは、ルーティングプロトコルの操作の一部として使用され（たとえば、コストをレイテンシで置き換えるか、帯域幅とコストを考慮することにより）、制約付きSPF（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 described in [RFC6375], or acting on it 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, care must be taken that measurement of the associated delay avoids significant queuing delay; that could be accomplished in a variety of ways, including either by measuring with a traffic class that experiences minimal queuing or by summing the measured link delays of the components of the link's path.
このドキュメントで説明するメカニズムは、パフォーマンス情報のみを配布することに注意してください。 [RFC6375]で説明されているように、そのパフォーマンス情報を最初に収集する方法、または配布された後にそれを処理する方法は、このドキュメントの範囲外です。 MPLSネットワークでの遅延、遅延変動、および損失を測定するメカニズムの例は、[RFC6374]で提供されています。このドキュメントではパフォーマンス情報を取得する方法を指定していませんが、遅延の測定値は、提供されたトラフィック負荷に基づいて大幅に変化してはなりません（SHOULD NOT）。したがって、キューイング遅延は遅延測定に含まれるべきではありません。 Forwarding Adjacencyなどのリンクの場合、関連する遅延を測定することで、重大なキューイング遅延が回避されるように注意する必要があります。これは、キューイングが最小限のトラフィッククラスで測定することや、リンクのパスのコンポーネントの測定されたリンク遅延を合計することなど、さまざまな方法で実現できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying the significance described in RFC 2119.
このドキュメントでは、これらの単語はすべて大文字の場合にのみその解釈で表示されます。これらの単語の小文字の使用は、RFC 2119に記載されている重要性を持つと解釈されるべきではありません。
This document registers new IS-IS TE sub-TLVs that can be announced in the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry in order to distribute network-performance information. The extensions in this document build on the ones provided in IS-IS TE [RFC5305] and GMPLS [RFC4203].
このドキュメントでは、ネットワークパフォーマンス情報を配信するために「TLV 22、23、141、222、および223のサブTLV」レジストリでアナウンスできる新しいIS-IS TEサブTLVを登録しています。このドキュメントの拡張は、IS-IS TE [RFC5305]およびGMPLS [RFC4203]で提供される拡張に基づいています。
IS-IS Extended Reachability TLV 22 (defined in [RFC5305]), Inter-AS Reachability Information TLV 141 (defined in [RFC5316]), and MT-ISIS TLV 222 (defined in [RFC5120]) have nested sub-TLVs that permit the TLVs to be readily extended. This document registers several sub-TLVs:
IS-IS拡張到達可能性TLV 22（[RFC5305]で定義）、AS間到達可能性情報TLV 141（[RFC5316]で定義）、およびMT-ISIS 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. These sub-TLVs could be used by the receiving node to determine whether to fail traffic to a backup path or whether to 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を使用して、バックアップパスへのトラフィックを失敗させるか、まったく新しいパスを計算するかを決定できます。 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 existing IS-IS TE specification [RFC5305], the bandwidth advertisements defined in this document MUST be encoded as IEEE floating-point values. 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浮動小数点値としてエンコードする必要があります。このドキュメントで定義されているdelayおよびdelay-variation通知は、整数値としてエンコードする必要があります。遅延値はマイクロ秒単位で定量化する必要があり、パケット損失は送信するパケットの割合として定量化する必要があり、帯域幅はバイト/秒として送信する必要があります。すべての値（残余帯域幅を除く）は、平均化期間が構成可能な期間でなければならないローリング平均として計算する必要があります。詳細については、セクション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 one (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: The A bit 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 clear, the sub-TLV represents steady-state link performance.
Aビット：Aビットは異常（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 sec), 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 one (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 clear, 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 the Min and Max delay to be the same value.
最小遅延と最大遅延が同じ値になる可能性があります。
When the delay value (Min or Max) is set to the maximum value 16,777,215 (16.777215 sec), 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 one (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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 sec), 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 one (i.e., the forward-path loss). 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Link Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
図4
where:
ただし：
Type: 36
タイプ：36
Length: 4
長さ：4
A bit: The A bit 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 clear, the sub-TLV represents steady-state link performance.
Aビット：Aビットは異常（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 assumption being that precision is more important on high-speed links than the ability to advertise loss rates greater than this, and that 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％です。この値は、表現できる最大パケット損失率です（高速リンクでは、これより大きな損失率をアドバタイズする機能よりも精度が重要であり、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 | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Residual Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type: 37
タイプ：37
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に設定する必要があり、受信時には無視する必要があります。
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]. Residual bandwidth 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 | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
図5
where:
ただし：
Type: 38
タイプ：38
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に設定する必要があり、受信時には無視する必要があります。
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 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ラベルスイッチドパスパケットの実際の転送に使用される測定帯域幅を引いたものとして定義されます。バンドルリンクの場合、使用可能な帯域幅は、コンポーネントリンクの使用可能な帯域幅から、非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 | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Utilized Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
図6
where:
ただし：
Type: 39
タイプ：39
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に設定する必要があり、受信時には無視する必要があります。
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 min/max delay and residual bandwidth) MUST represent an average over a period or be obtained by a filter that is reasonably representative of an average. For example, a rolling average is one such filter.
すべてのサブTLV（最小/最大遅延と残留帯域幅を除く）でアドバタイズされる値は、一定期間の平均を表すか、平均を合理的に表すフィルターによって取得する必要があります。たとえば、移動平均はそのようなフィルターの1つです。
Min and max 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 min and max 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 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 an advertisement interval(s) to permit fail back.
4. Aビットを含むサブTLVの場合、パフォーマンスが異常と見なされるしきい値に対応する追加のしきい値を含める必要があります（およびAビットのサブTLVが送信されます）。フェイルバックを許可するために、サブTLVのパフォーマンスがこのしきい値を下回る（または再クロスする）通知間隔で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 they are refreshed.
リンクパフォーマンスの値が、サブ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 1 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. Implementation SHOULD follow the described guidelines to mitigate the instability risk.
セクション7では、このドキュメントで定義されている新しいサブTLVがアドバタイズされるときに、ネットワークの安定性を確保するメカニズムについて説明します。実装は、不安定性のリスクを軽減するために、説明されているガイドラインに従う必要があります。
[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 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 result in a man-in-the-middle attacker delaying real-time data to a given site or destination, which could negatively affect the value of the data for that site or destination. The use of Link State PDU cryptographic authentication allows mitigation the risk of man-in-the-middle attack.
ほとんどの展開では、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単一方向利用帯域幅
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[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, <http://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月、<http ：//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, <http://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月、<http://www.rfc-editor.org/info/rfc5120>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<http://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, <http://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月、<http://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, <http://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月、< http://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, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6119] Harrison、J.、Berger、J。、およびM. Bartlett、「IS-ISでのIPv6トラフィックエンジニアリング」、RFC 6119、DOI 10.17487 / RFC6119、2011年2月、<http：//www.rfc-editor。 org / info / rfc6119>。
[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, <http://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月、<http://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, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K.、Ed。およびY. Rekhter編、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<http://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, <http://www.rfc-editor.org/info/rfc6374>.
[RFC6374] Frost、D。およびS. Bryant、「MPLSネットワークのパケット損失と遅延測定」、RFC 6374、DOI 10.17487 / RFC6374、2011年9月、<http://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, <http://www.rfc-editor.org/info/rfc6375>.
[RFC6375]フロスト、D、エド。およびS.ブライアント編、「MPLSベースのトランスポートネットワークのパケット損失および遅延測定プロファイル」、RFC 6375、DOI 10.17487 / RFC6375、2011年9月、<http://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, <http://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月、<http://www.rfc-editor.org/info/rfc7285>。
Acknowledgements
謝辞
The authors would like to recognize Ayman Soliman, Nabil Bitar, David McDysan, Les Ginsberg, Edward Crabbe, Don Fedyk, Hannes Gredler, Uma Chunduri, Alvaro Retana, Brian Weis, and Barry Leiba for their contribution and review of this document.
著者は、このドキュメントの寄稿とレビューについて、アイマンソリマン、ナビルビター、デビッドマクディサン、レジンスバーグ、エドワードクラブ、ドンフェディク、ハネスグレドラー、ウマチャンドゥリ、アルバロレタナ、ブライアンウェイス、バリーレイバを認めたいと思います。
The authors also recognize Curtis Villamizar for significant comments and direct content collaboration.
著者はまた、重要なコメントと直接的なコンテンツのコラボレーションについてCurtis Villamizarを認識しています。
Contributors
貢献者
The following people contributed substantially to the content of this document and should be considered co-authors:
次の人々はこのドキュメントの内容に実質的に貢献し、共著者と見なされるべきです：
Alia Atlas Juniper Networks United States
Alia Atlas Juniper Networksアメリカ合衆国
Email: akatlas@juniper.net
Clarence Filsfils Cisco Systems Inc. Belgium
Clarence Filsfils Cisco Systems Inc.ベルギー
Email: cfilsfil@cisco.com
Authors' Addresses
著者のアドレス
Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico 200 Rome 00191 Italy
Stefano Previdi（編集者）Cisco Systems、Inc. Via Del Serafico 200 Rome 00191イタリア
Email: sprevidi@cisco.com
Spencer Giacalone Microsoft
スペンサージャカロンマイクロソフト
Email: spencer.giacalone@gmail.com
Dave Ward Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 United States
Dave Ward Cisco Systems、Inc. 3700 Cisco Way San Jose、CA 95134アメリカ合衆国
Email: wardd@cisco.com
John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States
John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 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: sunseawq@huawei.com