[要約] RFC 8625は、Ethernetトラフィックパラメータと可用性情報に関する規格であり、Ethernetネットワークのトラフィック制御と可用性の向上を目的としています。
Internet Engineering Task Force (IETF) H. Long
Request for Comments: 8625 M. Ye, Ed.
Category: Standards Track Huawei Technologies Co., Ltd.
ISSN: 2070-1721 G. Mirsky, Ed.
ZTE
A. D'Alessandro
Telecom Italia S.p.A
H. Shah
Ciena
August 2019
Ethernet Traffic Parameters with Availability Information
可用性情報を含むイーサネットトラフィックパラメータ
Abstract
概要
A packet-switching network may contain links with variable bandwidths (e.g., copper and radio). The bandwidth of such links is sensitive to the external environment (e.g., climate). Availability is typically used to describe these links when doing network planning. This document introduces an optional Bandwidth Availability TLV in RSVP-TE signaling. This extension can be used to set up a GMPLS Label Switched Path (LSP) in conjunction with the Ethernet SENDER_TSPEC object.
パケット交換ネットワークには、帯域幅が可変のリンク（銅線や無線など）が含まれている場合があります。このようなリンクの帯域幅は、外部環境（気候など）の影響を受けます。可用性は通常、ネットワーク計画を行うときにこれらのリンクを記述するために使用されます。このドキュメントでは、RSVP-TEシグナリングのオプションの帯域幅可用性TLVを紹介します。この拡張機能を使用して、イーサネットSENDER_TSPECオブジェクトと組み合わせてGMPLSラベルスイッチドパス（LSP）を設定できます。
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/rfc8625.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8625で入手できます。
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. Conventions Used in This Document ..........................4
2. Overview ........................................................4
3. Extension to RSVP-TE Signaling ..................................5
3.1. Bandwidth Availability TLV .................................5
3.2. Signaling Process ..........................................6
4. Security Considerations .........................................7
5. IANA Considerations .............................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
Appendix A. Bandwidth Availability Example .......................11
Acknowledgments ...................................................13
Authors' Addresses ................................................13
The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] specify the signaling message, including the bandwidth request for setting up an LSP in a packet-switching network.
RSVP-TE仕様[RFC3209]およびGMPLS拡張[RFC3473]は、パケット交換ネットワークでLSPをセットアップするための帯域幅要求を含むシグナリングメッセージを指定します。
Some data communication technologies allow a seamless change of the maximum physical bandwidth through a set of known discrete values. The parameter availability [G.827] [F.1703] [P.530] is often used to describe the link capacity during network planning. The availability is based on a time scale, which is a proportion of the operating time that the requested bandwidth is ensured. A more detailed example of bandwidth availability can be found in Appendix A. Assigning different bandwidth availability classes to different types of services over links with variable discrete bandwidth provides for a more efficient planning of link capacity. To set up an LSP across these links, bandwidth availability information is required for the nodes to verify bandwidth satisfaction and make a bandwidth reservation. The bandwidth availability information should be inherited from the bandwidth availability requirements of the services expected to be carried on the LSP. For example, voice service usually needs 99.999% bandwidth availability, while non-real-time services may adequately perform at 99.99% or 99.9% bandwidth availability. Since different service types may need different availability guarantees, multiple <availability, bandwidth> pairs may be required when signaling.
一部のデータ通信テクノロジーでは、一連の既知の離散値を通じて最大物理帯域幅をシームレスに変更できます。パラメータの可用性[G.827] [F.1703] [P.530]は、ネットワーク計画中のリンク容量を記述するためによく使用されます。可用性は、要求された帯域幅が確保される稼働時間の割合である時間スケールに基づいています。帯域幅の可用性のより詳細な例は、付録Aにあります。さまざまな帯域幅の可用性クラスを、可変離散帯域幅のリンクを介してさまざまなタイプのサービスに割り当てると、リンク容量をより効率的に計画できます。これらのリンクにLSPを設定するには、ノードが帯域幅の満足度を確認し、帯域幅を予約するための帯域幅の可用性情報が必要です。帯域幅の可用性の情報は、LSPで伝送されることが予想されるサービスの帯域幅の可用性の要件から継承する必要があります。たとえば、音声サービスは通常99.999％の帯域幅の可用性を必要としますが、非リアルタイムサービスは99.99％または99.9％の帯域幅の可用性で十分に機能する可能性があります。異なるサービスタイプには異なる可用性の保証が必要な場合があるため、シグナリング時に複数の<可用性、帯域幅>ペアが必要になる場合があります。
If the bandwidth availability requirement is not specified in the signaling message, the bandwidth will likely be reserved as the highest bandwidth availability. Suppose, for example, the bandwidth with 99.999% availability of a link is 100 Mbps, and the bandwidth with 99.99% availability is 200 Mbps. When a video application makes a request for 120 Mbps without a bandwidth availability requirement, the system will consider the request as 120 Mbps with 99.999% bandwidth availability, while the available bandwidth with 99.999% bandwidth availability is only 100 Mbps. Therefore, the LSP path cannot be set up. However, the video application doesn't need 99.999% bandwidth availability; 99.99% bandwidth availability is enough. In this case, the LSP could be set up if the bandwidth availability is also specified in the signaling message.
帯域幅の可用性要件がシグナリングメッセージで指定されていない場合、帯域幅は最も高い帯域幅の可用性として予約される可能性があります。たとえば、リンクの可用性が99.999％の帯域幅が100 Mbpsであり、99.99％の可用性の帯域幅が200 Mbpsであるとします。ビデオアプリケーションが帯域幅の可用性を必要とせずに120 Mbpsを要求すると、システムはその要求を99.999％の帯域幅を利用できる120 Mbpsと見なしますが、99.999％の帯域幅を利用できる利用可能な帯域幅はわずか100 Mbpsです。そのため、LSPパスを設定できません。ただし、ビデオアプリケーションは99.999％の帯域幅の可用性を必要としません。 99.99％の帯域幅の可用性で十分です。この場合、帯域幅の可用性もシグナリングメッセージで指定されていれば、LSPを設定できます。
To fulfill an LSP setup by signaling in these scenarios, this document specifies a Bandwidth Availability TLV. The Bandwidth Availability TLV can be applicable to any kind of physical link with variable discrete bandwidth, such as microwave or DSL. Multiple Bandwidth Availability TLVs, together with multiple Ethernet Bandwidth Profile TLVs, can be carried by the Ethernet SENDER_TSPEC object [RFC6003]. Since the Ethernet FLOWSPEC object has the same format as the Ethernet SENDER_TSPEC object [RFC6003], the Bandwidth Availability TLV can also be carried by the Ethernet FLOWSPEC object.
これらのシナリオでシグナリングによってLSPセットアップを実現するために、このドキュメントでは帯域幅可用性TLVを指定しています。帯域幅可用性TLVは、マイクロ波やDSLなど、可変の離散帯域幅を持つあらゆる種類の物理リンクに適用できます。複数の帯域幅可用性TLVは、複数のイーサネット帯域幅プロファイルTLVとともに、イーサネットSENDER_TSPECオブジェクト[RFC6003]によって伝送できます。イーサネットFLOWSPECオブジェクトはイーサネットSENDER_TSPECオブジェクト[RFC6003]と同じ形式であるため、帯域幅可用性TLVはイーサネットFLOWSPECオブジェクトでも伝送できます。
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]で説明されているように解釈されます。
The following acronyms are used in this document:
このドキュメントでは、次の頭字語が使用されています。
RSVP-TE Resource Reservation Protocol - Traffic Engineering
RSVP-TEリソース予約プロトコル-トラフィックエンジニアリング
LSP Label Switched Path
LSPラベルスイッチドパス
SNR Signal-to-Noise Ratio
SNR信号対ノイズ比
TLV Type-Length-Value
TLVタイプ-長さ-値
LSA Link State Advertisement
LSAリンク状態アドバタイズメント
QAM Quadrature Amplitude Modulation
QAM直交振幅変調
QPSK Quadrature Phase Shift Keying
QPSK直交位相シフトキーイング
A tunnel in a packet-switching network may span one or more links in a network. To set up an LSP, a node may collect link information that is advertised in a routing message (e.g., an OSPF TE LSA message) by network nodes to obtain network topology information, and it can then calculate an LSP route based on the network topology. The calculated LSP route is signaled using a PATH/RESV message to set up the LSP.
パケット交換ネットワークのトンネルは、ネットワークの1つ以上のリンクにまたがることがあります。 LSPをセットアップするために、ノードはネットワークノードによってルーティングメッセージ（たとえば、OSPF TE LSAメッセージ）でアドバタイズされるリンク情報を収集してネットワークトポロジー情報を取得し、ネットワークトポロジーに基づいてLSPルートを計算できます。 。計算されたLSPルートは、LSPを設定するためのPATH / RESVメッセージを使用して通知されます。
If a network contains one or more links with variable discrete bandwidths, a <bandwidth, availability> requirement list should be specified for an LSP at setup. Each <bandwidth, availability> pair in the list means the listed bandwidth with specified availability is required. The list can be derived from the results of service planning for the LSP.
ネットワークに可変の離散帯域幅を持つ1つ以上のリンクが含まれている場合、セットアップ時にLSPの<bandwidth、availability>要件リストを指定する必要があります。リストの各<bandwidth、availability>ペアは、指定された可用性を持つリストされた帯域幅が必要であることを意味します。このリストは、LSPのサービス計画の結果から導き出すことができます。
A node that has link(s) with variable discrete bandwidth attached should contain a <bandwidth, availability> information list in its OSPF TE LSA messages. The list provides the mapping between the link nominal bandwidth and its availability level. This information can then be used for path calculation by the node(s). The routing extension for availability can be found in [RFC8330].
可変離散帯域幅が接続されたリンクを持つノードは、OSPF TE LSAメッセージに<bandwidth、availability>情報リストを含める必要があります。このリストは、リンクの公称帯域幅とその可用性レベルの間のマッピングを提供します。この情報は、ノードによるパス計算に使用できます。可用性のためのルーティング拡張は[RFC8330]にあります。
When a node initiates a PATH/RESV signaling to set up an LSP, the PATH message should carry the <bandwidth, availability> requirement list as a bandwidth request. Intermediate node(s) will allocate the bandwidth resources for each availability requirement from the remaining bandwidth with the corresponding availability. An error message may be returned if any <bandwidth, availability> request cannot be satisfied.
ノードがLSPをセットアップするためにPATH / RESVシグナリングを開始すると、PATHメッセージは<bandwidth、availability>要件リストを帯域幅要求として運ぶ必要があります。中間ノードは、対応する可用性を備えた残りの帯域幅から、各可用性要件に帯域幅リソースを割り当てます。 <bandwidth、availability>要求をすべて満たすことができない場合、エラーメッセージが返されることがあります。
A Bandwidth Availability TLV is defined as a TLV of the Ethernet SENDER_TSPEC object [RFC6003] in this document. The Ethernet SENDER_TSPEC object MAY include more than one Bandwidth Availability TLV. The Bandwidth Availability TLV has the following format:
Bandwidth Availability TLVは、このドキュメントではイーサネットSENDER_TSPECオブジェクト[RFC6003]のTLVとして定義されています。イーサネットSENDER_TSPECオブジェクトには、複数の帯域幅可用性TLVが含まれる場合があります。 Bandwidth Availability 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Availability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Bandwidth Availability TLV
図1：帯域幅可用性TLV
Type (2 octets): 4
タイプ（2オクテット）：4
Length (2 octets): 0x0C. Indicates the length in bytes of the whole TLV, including the Type and Length fields. In this case, the length is 12 bytes.
長さ（2オクテット）：0x0C。 TypeおよびLengthフィールドを含むTLV全体の長さをバイト単位で示します。この場合、長さは12バイトです。
Index (1 octet): When the Bandwidth Availability TLV is included, the Ethernet Bandwidth Profile TLV MUST also be included. If there are multiple bandwidth requirements present (in multiple Ethernet Bandwidth Profile TLVs) and they have different availability requirements, multiple Bandwidth Availability TLVs MUST be carried. In such a case, the Bandwidth Availability TLV has a one-to-one correspondence with the Ethernet Bandwidth Profile TLV as both have the same value in the Index field. If all the bandwidth requirements in the Ethernet Bandwidth Profile TLV have the same availability requirement, one Bandwidth Availability TLV SHOULD be carried. In this case, the Index field is set to 0.
インデックス（1オクテット）：帯域幅可用性TLVが含まれている場合、イーサネット帯域幅プロファイルTLVも含まれている必要があります。複数の帯域幅要件が存在し（複数のイーサネット帯域幅プロファイルTLV）、それらに異なる可用性要件がある場合、複数の帯域幅可用性TLVを実行する必要があります。このような場合、Bandwidth Availability TLVは、Ethernet Bandwidth Profile TLVと1対1で対応します。これは、両方ともIndexフィールドに同じ値があるためです。イーサネット帯域幅プロファイルTLVのすべての帯域幅要件に同じ可用性要件がある場合、1つの帯域幅可用性TLVを伝送する必要があります（SHOULD）。この場合、Indexフィールドは0に設定されます。
Reserved (3 octets): These bits SHOULD be set to zero when sent and MUST be ignored when received.
予約済み（3オクテット）：これらのビットは送信時にゼロに設定する必要があり（SHOULD）、受信時に無視する必要があります。
Availability (4 octets): A 32-bit floating-point number in binary interchange format [IEEE754] describes the decimal value of the availability requirement for this bandwidth request. The value MUST be less than 1 and is usually expressed as one of the following values: 0.99, 0.999, 0.9999, or 0.99999. The IEEE floating-point number is used here to align with [RFC8330]. When representing values higher than 0.999999, the floating-point number starts to introduce errors to intended precision. However, in reality, 0.99999 is normally considered the highest availability value (which results in 5 minutes of outage in a year) in a telecom network. Therefore, the use of a floating-point number for availability is acceptable.
可用性（4オクテット）：2進交換形式の32ビット浮動小数点数[IEEE754]は、この帯域幅要求の可用性要件の10進値を示しています。値は1未満でなければならず、通常は0.99、0.999、0.9999、または0.99999のいずれかの値として表されます。 IEEE浮動小数点数は、ここで[RFC8330]に合わせるために使用されます。 0.999999より大きい値を表す場合、浮動小数点数は、意図した精度にエラーを導入し始めます。ただし実際には、0.99999は通常、テレコムネットワークでの最高の可用性値（1年で5分の停止という結果になる）と見なされます。したがって、可用性のために浮動小数点数を使用することは許容されます。
The source node initiates a PATH message, which may carry a number of bandwidth requests, including one or more Ethernet Bandwidth Profile TLVs and one or more Bandwidth Availability TLVs. Each Ethernet Bandwidth Profile TLV corresponds to an availability parameter in the associated Bandwidth Availability TLV.
ソースノードはPATHメッセージを開始します。PATHメッセージには、1つ以上のイーサネット帯域幅プロファイルTLVと1つ以上の帯域幅可用性TLVを含む、多数の帯域幅要求が含まれる場合があります。各イーサネット帯域幅プロファイルTLVは、関連する帯域幅可用性TLVの可用性パラメータに対応しています。
When the intermediate and destination nodes receive the PATH message, the nodes compare the requested bandwidth under each availability level in the SENDER_TSPEC objects, with the remaining link bandwidth resources under a corresponding availability level on a local link, to check if they can meet the bandwidth requirements.
中間ノードと宛先ノードがPATHメッセージを受信すると、ノードはSENDER_TSPECオブジェクトの各可用性レベルの下で要求された帯域幅を、ローカルリンク上の対応する可用性レベルの下の残りのリンク帯域幅リソースと比較して、帯域幅を満たすことができるかどうかを確認します要件。
o When all <bandwidth, availability> requirement requests can be satisfied (that is, the requested bandwidth under each availability parameter is smaller than or equal to the remaining bandwidth under the corresponding availability parameter on its local link), the node SHOULD reserve the bandwidth resources from each remaining sub-bandwidth portion on its local link to set up this LSP. Optionally, a higher availability bandwidth can be allocated to a lower availability request when the lower availability bandwidth cannot satisfy the request.
o すべての<bandwidth、availability>要件の要求を満たすことができる場合（つまり、各可用性パラメーターの下で要求された帯域幅が、ローカルリンク上の対応する可用性パラメーターの下の残りの帯域幅以下である場合）、ノードは帯域幅リソースを予約する必要があります（SHOULD）ローカルリンク上の残りの各サブ帯域幅部分から、このLSPをセットアップします。オプションで、低い可用性の帯域幅が要求を満たせない場合、高い可用性の帯域幅を低い可用性の要求に割り当てることができます。
o When at least one <bandwidth, availability> requirement request cannot be satisfied, the node SHOULD generate a PathErr message with the error code "Admission Control Error" and the error value "Requested Bandwidth Unavailable" (see [RFC2205]).
o 少なくとも1つの<bandwidth、availability>要件の要求を満たすことができない場合、ノードは、エラーコード「Admission Control Error」とエラー値「Requested Bandwidth Unavailable」を含むPathErrメッセージを生成する必要があります（[RFC2205]を参照）。
When two LSPs request bandwidth with the same availability requirement, the contention MUST be resolved by comparing the node IDs, where the LSP with the higher node ID is assigned the reservation. This is consistent with the general contention resolution mechanism provided in Section 4.2 of [RFC3471].
2つのLSPが同じ可用性要件で帯域幅を要求する場合、ノードIDを比較して競合を解決する必要があります。ノードIDの大きいLSPに予約が割り当てられます。これは、[RFC3471]のセクション4.2で提供されている一般的な競合解決メカニズムと一致しています。
When a node does not support the Bandwidth Availability TLV, the node should send a PathErr message with error code "Unknown Attributes TLV", as specified in [RFC5420]. An LSP could also be set up in this case if there's enough bandwidth (note that the availability level of the reserved bandwidth is unknown). When a node receives Bandwidth Availability TLVs with a mix of zero and non-zero indexes, the message MUST be ignored and MUST NOT be propagated. When a node receives Bandwidth Availability TLVs (non-zero index) with no matching index value among the Ethernet Bandwidth Profile TLVs, the message MUST be ignored and MUST NOT be propagated. When a node receives several <bandwidth, availability> pairs, but there are extra Ethernet Bandwidth Profile TLVs that do not match the index of any Bandwidth Availability TLV, the extra Ethernet Bandwidth Profile TLVs MUST be ignored and MUST NOT be propagated.
ノードがBandwidth Availability TLVをサポートしていない場合、[RFC5420]で指定されているように、ノードはエラーコード「不明な属性TLV」を含むPathErrメッセージを送信する必要があります。この場合、十分な帯域幅があればLSPを設定することもできます（予約済み帯域幅の可用性レベルは不明であることに注意してください）。ノードがゼロと非ゼロのインデックスが混在する帯域幅可用性TLVを受信する場合、メッセージは無視されなければならず、伝播されてはなりません（MUST NOT）。ノードがイーサネット帯域幅プロファイルTLVの中で一致するインデックス値のない帯域幅可用性TLV（ゼロ以外のインデックス）を受信する場合、メッセージは無視されなければならず、伝播されてはなりません（MUST NOT）。ノードが複数の<帯域幅、可用性>ペアを受信したが、どの帯域幅可用性TLVのインデックスとも一致しない追加のイーサネット帯域幅プロファイルTLVがある場合、追加のイーサネット帯域幅プロファイルTLVは無視する必要があり、伝播してはなりません。
This document defines a Bandwidth Availability TLV in RSVP-TE signaling used in GMPLS networks. [RFC3945] notes that authentication in GMPLS systems may use the authentication mechanisms of the component protocols. [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. In particular, Section 7.1.2 of [RFC5920] discusses the control-plane protection with RSVP-TE by using general RSVP security tools, limiting the impact of an attack on control-plane resources, and using authentication for RSVP messages. Moreover, the GMPLS network is often considered to be a closed network such that insertion, modification, or inspection of packets by an outside party is not possible.
このドキュメントでは、GMPLSネットワークで使用されるRSVP-TEシグナリングの帯域幅可用性TLVを定義します。 [RFC3945]は、GMPLSシステムでの認証は、コンポーネントプロトコルの認証メカニズムを使用する可能性があると述べています。 [RFC5920]は、GMPLSコントロールプレーンのセキュリティの脆弱性と保護メカニズムの概要を提供します。特に、[RFC5920]のセクション7.1.2では、一般的なRSVPセキュリティツールを使用し、コントロールプレーンリソースへの攻撃の影響を制限し、RSVPメッセージに認証を使用することによる、RSVP-TEによるコントロールプレーンの保護について説明します。さらに、GMPLSネットワークは外部ネットワークによるパケットの挿入、変更、または検査ができないような閉じたネットワークと見なされることがよくあります。
IANA maintains a registry of GMPLS parameters called the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry. This registry includes the "Ethernet Sender TSpec TLVs/ Ethernet Flowspec TLVs" subregistry that contains the TLV type values for TLVs carried in the Ethernet SENDER_TSPEC object. This subregistry has been updated to include the Bandwidth Availability TLV:
IANAは、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Parameters」レジストリと呼ばれるGMPLSパラメータのレジストリを維持しています。このレジストリには、Ethernet SENDER_TSPECオブジェクトで伝送されるTLVのTLVタイプ値を含む「Ethernet Sender TSpec TLVs / Ethernet Flowspec TLVs」サブレジストリが含まれています。このサブレジストリは、帯域幅可用性TLVを含むように更新されました。
Type Description Reference
---- ---------------------- ---------
4 Bandwidth Availability RFC 8625
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754, DOI 10.1109/IEEESTD.2008.4610935.
[IEEE754] IEEE、「IEEE Standard for Floating-Point Arithmetic」、IEEE 754、DOI 10.1109 / IEEESTD.2008.4610935。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<https://www.rfc-editor.org/info/rfc2205>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <https://www.rfc-editor.org/info/rfc3471>.
[RFC3471] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、DOI 10.17487 / RFC3471、2003年1月、<https://www.rfc-editor.org/ info / rfc3471>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<https： //www.rfc-editor.org/info/rfc3473>。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <https://www.rfc-editor.org/info/rfc5420>.
[RFC5420] Farrel、A.、Ed。、Papadimitriou、D.、Vasseur、JP。、およびA. Ayyangarps、「Resource Reservation Protocol Traffic Engineering（RSVP-TE）を使用したMPLS LSP確立のための属性のエンコーディング」、RFC 5420、 DOI 10.17487 / RFC5420、2009年2月、<https://www.rfc-editor.org/info/rfc5420>。
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC 6003, DOI 10.17487/RFC6003, October 2010, <https://www.rfc-editor.org/info/rfc6003>.
[RFC6003] Papadimitriou、D。、「イーサネットトラフィックパラメータ」、RFC 6003、DOI 10.17487 / RFC6003、2010年10月、<https://www.rfc-editor.org/info/rfc6003>。
[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>。
[EN-302-217] ETSI, "Fixed Radio Systems; Characteristics and requirements for point-to-point equipment and antennas; Part 1: Overview and system-independent common characteristics", ETSI EN 302 217-1, Version 3.1.1, May 2017.
[EN-302-217] ETSI、「固定無線システム、ポイントツーポイント機器とアンテナの特性と要件、パート1：概要とシステムに依存しない共通の特性」、ETSI EN 302 217-1、バージョン3.1.1 、2017年5月。
[F.1703] ITU-R, "Availability objectives for real digital fixed wireless links used in 27 500 km hypothetical reference paths and connections", ITU-R Recommendation F.1703-0, January 2005, <https://www.itu.int/rec/R-REC-F.1703/en>.
[F.1703] ITU-R、「27 500 kmの架空の参照パスおよび接続で使用される実際のデジタル固定ワイヤレスリンクの可用性目標」、ITU-R勧告F.1703-0、2005年1月、<https：// www。 itu.int/rec/R-REC-F.1703/en>。
[G.827] ITU-T, "Availability performance parameters and objectives for end-to-end international constant bit-rate digital paths", ITU-T Recommendation G.827, September 2003, <https://www.itu.int/rec/T-REC-G.827/en>.
[G.827] ITU-T、「エンドツーエンドの国際的な固定ビットレートデジタルパスの可用性パフォーマンスパラメータと目標」、ITU-T勧告G.827、2003年9月、<https：//www.itu。 int / rec / T-REC-G.827 / en>。
[P.530] ITU-R, "Propagation data and prediction methods required for the design of terrestrial line-of-sight systems", ITU-R Recommendation P.530-17, December 2017, <https://www.itu.int/rec/R-REC-P.530/en>.
[P.530] ITU-R、「地上の見通しシステムの設計に必要な伝播データと予測方法」、ITU-R勧告P.530-17、2017年12月、<https：//www.itu .int / rec / R-REC-P.530 / en>。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <https://www.rfc-editor.org/info/rfc3945>.
[RFC3945] Mannie、E。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、DOI 10.17487 / RFC3945、2004年10月、<https://www.rfc-editor.org/info/ rfc3945>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[RFC8330] Long, H., Ye, M., Mirsky, G., D'Alessandro, A., and H. Shah, "OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth", RFC 8330, DOI 10.17487/RFC8330, February 2018, <https://www.rfc-editor.org/info/rfc8330>.
[RFC8330] Long、H.、Ye、M.、Mirsky、G.、D'Alessandro、A.、and H. Shah、 "OSPF Traffic Engineering（OSPF-TE）Link Availability Extension for Links with Variable Discrete Bandwidth"、 RFC 8330、DOI 10.17487 / RFC8330、2018年2月、<https://www.rfc-editor.org/info/rfc8330>。
In mobile backhaul networks, microwave links are very popular for providing connections of last hops. To maintain link connectivity in heavy rain conditions, the microwave link may lower the modulation level since moving to a lower modulation level provides for a lower SNR requirement. This is called "adaptive modulation" technology [EN-302-217]. However, a lower modulation level also means a lower link bandwidth. When a link bandwidth is reduced because of modulation downshifting, high-priority traffic can be maintained, while lower-priority traffic is dropped. Similarly, copper links may change their link bandwidth due to external interference.
モバイルバックホールネットワークでは、マイクロ波リンクはラストホップの接続を提供するために非常に人気があります。大雨の状況でもリンク接続を維持するために、マイクロ波リンクは変調レベルを下げることがあります。これは、低い変調レベルに移動すると、SNR要件が低くなるためです。これは「適応変調」技術と呼ばれます[EN-302-217]。ただし、変調レベルが低いほど、リンク帯域幅も低くなります。変調ダウンシフトのためにリンク帯域幅が減少すると、優先度の低いトラフィックはドロップされ、優先度の高いトラフィックは維持されます。同様に、銅線リンクは外部干渉のためにリンク帯域幅を変更する場合があります。
Presume that a link has three discrete bandwidth levels:
リンクに3つの個別の帯域幅レベルがあると仮定します。
o The link bandwidth under modulation level 1 (e.g., QPSK) is 100 Mbps.
o 変調レベル1（QPSKなど）でのリンク帯域幅は100 Mbpsです。
o The link bandwidth under modulation level 2 (e.g., 16QAM) is 200 Mbps.
o 変調レベル2（16QAMなど）でのリンク帯域幅は200 Mbpsです。
o The link bandwidth under modulation level 3 (e.g., 256QAM) is 400 Mbps.
o 変調レベル3（256QAMなど）でのリンク帯域幅は400 Mbpsです。
On a sunny day, modulation level 3 can be used to achieve a 400 Mbps link bandwidth.
晴れた日には、変調レベル3を使用して、400 Mbpsのリンク帯域幅を実現できます。
Light rain with a X mm/h rate triggers the system to change the modulation level from level 3 to level 2, with the bandwidth changing from 400 Mbps to 200 Mbps. The probability of X mm/h rain in the local area is 52 minutes in a year. Then the dropped 200 Mbps bandwidth has 99.99% availability.
X mm / hレートの小雨により、システムは変調レベルをレベル3からレベル2に変更し、帯域幅は400 Mbpsから200 Mbpsに変更されます。ローカルエリアでのX mm / hの雨の確率は、年間52分です。その後、200 Mbpsの帯域幅が失われた場合、可用性は99.99％になります。
Heavy rain with a Y(Y>X) mm/h rate triggers the system to change the modulation level from level 2 to level 1, with the bandwidth changing from 200 Mbps to 100 Mbps. The probability of Y mm/h rain in the local area is 26 minutes in a year. Then the dropped 100 Mbps bandwidth has 99.995% availability.
Y（Y> X）mm / hレートの大雨が発生すると、システムは変調レベルをレベル2からレベル1に変更し、帯域幅を200 Mbpsから100 Mbpsに変更します。ローカルエリアでのY mm / hの雨の確率は、1年で26分です。次に、ドロップされた100 Mbps帯域幅の可用性は99.995％になります。
For the 100 Mbps bandwidth of modulation level 1, only extreme weather conditions can cause the whole system to be unavailable, which only happens for 5 minutes in a year. So the 100 Mbps bandwidth of the modulation level 1 owns the availability of 99.999%.
変調レベル1の100 Mbps帯域幅の場合、極端な気象条件が原因でシステム全体が使用できなくなる可能性があります。これは1年に5分間しか発生しません。したがって、変調レベル1の100 Mbps帯域幅は99.999％の可用性を所有します。
There are discrete buckets per availability level. Under the worst weather conditions, there's only 100 Mbps capacity, which is 99.999% available. It's treated effectively as "always available" since better availability is not possible. If the weather is bad but not the worst possible conditions, modulation level 2 can be used, which gets an additional 100 Mbps bandwidth (i.e., 200 Mbps total). Therefore, 100 Mbps is in the 99.999% bucket, and 100 Mbps is in the 99.995% bucket. In clear weather, modulation level 3 can be used to get 400 Mbps total, but that's only 200 Mbps more than at modulation level 2, so the 99.99% bucket has that "extra" 200 Mbps, and the other two buckets still have 100 Mbps each.
可用性レベルごとに個別のバケットがあります。最悪の気象条件では、100 Mbpsの容量しかなく、99.999％が利用可能です。可用性を高めることができないため、「常に利用可能」として効果的に処理されます。悪天候ではあるが最悪の状況ではない場合は、変調レベル2を使用できます。これにより、100 Mbpsの帯域幅が追加されます（つまり、合計で200 Mbps）。したがって、100 Mbpsは99.999％バケットにあり、100 Mbpsは99.995％バケットにあります。晴天時には、変調レベル3を使用して合計400 Mbpsを取得できますが、変調レベル2の場合よりも200 Mbpsだけ高いので、99.99％のバケットには「余分な」200 Mbpsがあり、他の2つのバケットにはまだ100 Mbpsがあります。各。
Therefore, the maximum bandwidth is 400 Mbps. The sub-bandwidth and its availability according to the weather conditions are shown as follows:
したがって、最大帯域幅は400 Mbpsです。気象条件に応じたサブ帯域幅とその可用性は次のように表示されます。
Sub-bandwidth (Mbps) Availability
------------------ ------------
200 99.99%
２００ ９９。９９％
100 99.995%
１００ ９９。９９５％
100 99.999%
１００ ９９。９９９％
Acknowledgments
謝辞
The authors would like to thank Deborah Brungard, Khuzema Pithewan, Lou Berger, Yuji Tochio, Dieter Beller, and Autumn Liu for their comments on and contributions to the document.
著者は、このドキュメントに対するコメントと貢献に対して、Deborah Brungard、Khuzema Pithewan、Lou Berger、Yuchi Tochio、Dieter Beller、およびAutumn Liuに感謝します。
Authors' Addresses
著者のアドレス
Hao Long Huawei Technologies Co., Ltd. No.1899, Xiyuan Avenue, Hi-tech Western District Chengdu 611731 China
H AO長いhu Aはテクノロジー株式会社1899、99元通り、ハイテク西部地区チェンチェン611731中国を読む
Phone: +86-18615778750
Email: longhao@huawei.com
Min Ye (editor) Huawei Technologies Co., Ltd. No.1899, Xiyuan Avenue, Hi-tech Western District Chengdu 611731 China
最小Y（編集者）hu Aはテクノロジーズ株式会社、1899年、ξ元通り、ハイテク西部地区Cheng読み取り611731中国
Email: amy.yemin@huawei.com
Greg Mirsky (editor) ZTE
グレッグ・ミルスキー（編集者）ZTE
Email: gregimirsky@gmail.com
Alessandro D'Alessandro Telecom Italia S.p.A
アレッサンドロダレッサンドロテレコムイタリアS.p.A
Email: alessandro.dalessandro@telecomitalia.it
Himanshu Shah Ciena Corp. 3939 North First Street San Jose, CA 95134 United States of America
Himanshu Shah Ciena Corp. 3939 North First Street San Jose、CA 95134アメリカ合衆国
Email: hshah@ciena.com