[要約] RFC 8919は、IS-ISルーティングプロトコルにおけるアプリケーション固有のリンク属性を定義します。この文書の目的は、ネットワークの特定の要件に合わせてリンク属性をカスタマイズし、より効率的なルーティングとリソース利用を可能にすることです。利用場面には、帯域幅の最適化、遅延の最小化、特定のアプリケーションやサービスの要件に合わせたネットワークの調整が含まれます。
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 8919 P. Psenak
Category: Standards Track Cisco Systems
ISSN: 2070-1721 S. Previdi
Huawei Technologies
W. Henderickx
Nokia
J. Drake
Juniper Networks
October 2020
IS-IS Application-Specific Link Attributes
IS-ISアプリケーション固有のリンク属性
Abstract
概要
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings.
既存のトラフィックエンジニアリング関連リンク属性広告が定義されており、RSVP-TE展開で使用されています。元のRSVP-TEユースケースが定義されているので、リンク属性広告を利用する追加のアプリケーション（例えば、セグメントルーティングポリシーおよびループフリーの代替）が定義されている。複数のアプリケーションがこれらのリンク属性を利用したい場合、現在のアドバタライズメントは特定の属性のアプリケーション固有の値をサポートしていません。また、特定のリンクに対してアドバタイズされた値を使用しているアプリケーションの表示をサポートしません。この文書では、これらの欠点の両方に対処する新しいリンク属性広告を紹介します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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）の製品です。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/rfc8919.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8919で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. Requirements Discussion
3. Legacy Advertisements
3.1. Legacy Sub-TLVs
3.2. Legacy SRLG Advertisements
4. Advertising Application-Specific Link Attributes
4.1. Application Identifier Bit Mask
4.2. Application-Specific Link Attributes Sub-TLV
4.2.1. Special Considerations for Maximum Link Bandwidth
4.2.2. Special Considerations for Reservable/Unreserved
Bandwidth
4.2.3. Considerations for Extended TE Metrics
4.3. Application-Specific SRLG TLV
5. Attribute Advertisements and Enablement
6. Deployment Considerations
6.1. Use of Legacy Advertisements
6.2. Use of Zero-Length Application Identifier Bit Masks
6.3. Interoperability, Backwards Compatibility, and Migration
Concerns
6.3.1. Multiple Applications: Common Attributes with RSVP-TE
6.3.2. Multiple Applications: All Attributes Not Shared with
RSVP-TE
6.3.3. Interoperability with Legacy Routers
6.3.4. Use of Application-Specific Advertisements for RSVP-TE
7. IANA Considerations
7.1. Application-Specific Link Attributes Sub-TLV
7.2. Application-Specific SRLG TLV
7.3. Sub-sub-TLV Codepoints for Application-Specific Link
Attributes Registry
7.4. Link Attribute Application Identifiers Registry
7.5. Sub-TLVs for TLV 238 Registry
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
Advertisement of link attributes by the Intermediate System to Intermediate System (IS-IS) protocol in support of traffic engineering (TE) was introduced by [RFC5305] and extended by [RFC5307], [RFC6119], [RFC7308], and [RFC8570]. Use of these extensions has been associated with deployments supporting Traffic Engineering over Multiprotocol Label Switching (MPLS) in the presence of the Resource Reservation Protocol (RSVP), more succinctly referred to as RSVP-TE [RFC3209].
トラフィックエンジニアリング（TE）をサポートする中間システム（IS - IS）プロトコルによるリンク属性の広告（TE）は[RFC5305]によって導入され、[RFC5307]、[RFC6119]、[RFC7308]、[RFC8570]。これらの拡張機能を使用すると、リソース予約プロトコル（RSVP）が存在する、マルチプロトコルラベルスイッチング（MPLS）を介したトラフィックエンジニアリングをサポートする展開に関連付けられています。
For the purposes of this document, an application is a technology that makes use of link attribute advertisements, examples of which are listed in Section 3.
この文書の目的のために、アプリケーションはリンク属性広告を利用する技術であり、その例はセクション3にリストされている。
In recent years, new applications that have use cases for many of the link attributes historically used by RSVP-TE have been introduced. Such applications include Segment Routing (SR) Policy [SEGMENT-ROUTING] and Loop-Free Alternates (LFAs) [RFC5286]. This has introduced ambiguity in that if a deployment includes a mix of RSVP-TE support and SR Policy support, for example, it is not possible to unambiguously indicate which advertisements are to be used by RSVP-TE and which advertisements are to be used by SR Policy. If the topologies are fully congruent, this may not be an issue, but any incongruence leads to ambiguity.
近年、RSVP-TEが歴史的に使用されているリンク属性の多くの使用症例を持つ新しいアプリケーションが導入されました。そのようなアプリケーションには、セグメントルーティング（SR）ポリシー[セグメントルーティング]とループフリーの代替（LFAS）[RFC5286]があります。これは、展開にRSVP-TEサポートとSRポリシーサポートの組み合わせが含まれている場合、RSVP-TEによってどの広告が使用されるべきか、どの広告を使用するかを明確に示すことは不可能ではないという点であいまいさが曖昧さを導入しました。SRポリシー。トポロジが完全に一致している場合、これは問題にならないかもしれませんが、不況はあいまいさにつながります。
An example of where this ambiguity causes a problem is a network where RSVP-TE is enabled only on a subset of its links. A link attribute is advertised for the purpose of another application (e.g., SR Policy) for a link that is not enabled for RSVP-TE. As soon as the router that is an RSVP-TE head end sees the link attribute being advertised for that link, it assumes RSVP-TE is enabled on that link, even though it is not. If such an RSVP-TE head-end router tries to set up an RSVP-TE path via that link, it will result in a path setup failure.
このあいまいさが問題を引き起こす場所の例は、RSVP-TEがそのリンクのサブセットでのみ有効になっているネットワークです。link属性は、RSVP-TEに対して有効になっていないリンクのための別のアプリケーション（例えばSRポリシー）の目的のためにアドバタイズされます。RSVP-TEヘッドエンドであるルータがそのリンクのためにアドバタイズされているリンク属性を見るとすぐに、それはそのリンクでRSVP-TEが有効になっています。そのようなRSVP-TEヘッドエンド・ルータがそのリンクを介してRSVP-TEパスを設定しようとすると、パス設定の失敗が発生します。
An additional issue arises in cases where both applications are supported on a link but the link attribute values associated with each application differ. Current advertisements do not support advertising application-specific values for the same attribute on a specific link.
両方のアプリケーションがリンクでサポートされているが、各アプリケーションに関連付けられているリンク属性値が異なる場合に追加の問題が発生します。現在の広告は、特定のリンク上の同じ属性に対するアプリケーション固有の値の広告をサポートしません。
This document defines extensions that address these issues. Also, as evolution of use cases for link attributes can be expected to continue in the years to come, this document defines a solution that is easily extensible to the introduction of new applications and new use cases.
この文書はこれらの問題に対処する拡張機能を定義しています。また、リンク属性のユースケースの進化が続く前に続くと予想されるので、この文書は新しいアプリケーションの導入と新しいユースケースの導入に容易に拡張可能な解決策を定義します。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
As stated previously, evolution of use cases for link attributes can be expected to continue. Therefore, any discussion of existing use cases is limited to requirements that are known at the time of this writing. However, in order to determine the functionality required beyond what already exists in IS-IS, it is only necessary to discuss use cases that justify the key points identified in the introduction, which are:
以前に述べたように、リンク属性のユースケースの進化は継続すると予想されます。したがって、既存のユースケースの議論は、この書き込み時に知られている要件に限定されています。ただし、既にIS-ISに存在するものを超えて必要な機能を判断するためには、紹介時に識別されたキーポイントを正当化するユースケースを議論する必要があるだけです。
1. Support for indicating which applications are using the link attribute advertisements on a link
1. リンク上のリンク属性広告を使用しているアプリケーションがどのアプリケーションで使用しているかを示すサポート
2. Support for advertising application-specific values for the same attribute on a link
2. リンク上の同じ属性に対する広告アプリケーション固有の値のサポート
[RFC7855] discusses use cases and requirements for Segment Routing (SR). Included among these use cases is SR Policy, which is defined in [SEGMENT-ROUTING]. If both RSVP-TE and SR Policy are deployed in a network, link attribute advertisements can be used by one or both of these applications. There is no requirement for the link attributes advertised on a given link used by SR Policy to be identical to the link attributes advertised on that same link used by RSVP-TE; thus, there is a clear requirement to indicate independently which link attribute advertisements are to be used by each application.
[RFC7855]セグメントルーティング（SR）の使用例と要件について説明します。これらのユースケースの中に含まれるのはSRポリシーです。これは[セグメントルーティング]で定義されています。RSVP-TEおよびSRポリシーの両方がネットワークにデプロイされている場合、リンク属性広告はこれらのアプリケーションの一方または両方で使用できます。SRポリシーによって使用される特定のリンクでアドバタイズされたリンク属性は、RSVP-TEによって使用されるその同じリンクでアドバタイズされたリンク属性と同一である必要はありません。したがって、どのリンク属性広告が各アプリケーションによって使用されるべきかを独立して示すための明確な要件がある。
As the number of applications that may wish to utilize link attributes may grow in the future, an additional requirement is that the extensions defined allow the association of additional applications to link attributes without altering the format of the advertisements or introducing new backwards-compatibility issues.
リンク属性を利用することを望む可能性があるアプリケーションの数が将来増大する可能性があるため、追加の要件は、拡張機能が定義されているということであり、追加のアプリケーションの関連付けが広告のフォーマットを変更せずに属性をリンクしたり、新しい下位互換性の問題を導入することができます。
Finally, there may still be many cases where a single attribute value can be shared among multiple applications, so the solution must minimize advertising duplicate link/attribute pairs whenever possible.
最後に、単一の属性値を複数のアプリケーション間で共有できる場合があるため、可能な限り広告の重複リンク/属性ペアを最小限に抑える必要があります。
Existing advertisements used in support of RSVP-TE include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link Group (SRLG) advertisement.
RSVP-TEをサポートして使用されている既存の広告には、TLV 22,23,25,141,222、および223、および共有リスクリンクグループ（SRLG）広告のためのTLVのサブTLVが含まれます。
Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223" registry.
サブTLV値は、「TLV22,23,25,141,222、および222」レジストリの「サブTLV」で定義されています。
TLVs are defined in the "TLV Codepoints Registry".
TLVは "TLV CodePointsレジストリ"で定義されています。
+======+====================================+
| Type | Description |
+======+====================================+
| 3 | Administrative group (color) |
+------+------------------------------------+
| 9 | Maximum link bandwidth |
+------+------------------------------------+
| 10 | Maximum reservable link bandwidth |
+------+------------------------------------+
| 11 | Unreserved bandwidth |
+------+------------------------------------+
| 14 | Extended Administrative Group |
+------+------------------------------------+
| 18 | TE Default Metric |
+------+------------------------------------+
| 33 | Unidirectional Link Delay |
+------+------------------------------------+
| 34 | Min/Max Unidirectional Link Delay |
+------+------------------------------------+
| 35 | Unidirectional Delay Variation |
+------+------------------------------------+
| 36 | Unidirectional Link Loss |
+------+------------------------------------+
| 37 | Unidirectional Residual Bandwidth |
+------+------------------------------------+
| 38 | Unidirectional Available Bandwidth |
+------+------------------------------------+
| 39 | Unidirectional Utilized Bandwidth |
+------+------------------------------------+
Table 1: Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223
表1：TLV 22,23,25,141,222、および223のサブTLV
TLV 138 (GMPLS-SRLG): Supports links identified by IPv4 addresses and unnumbered links.
TLV 138（GMPLS-SRLG）：IPv4アドレスと番号なしリンクによって識別されるリンクをサポートします。
TLV 139 (IPv6 SRLG): Supports links identified by IPv6 addresses.
TLV 139（IPv6 SRLG）：IPv6アドレスで識別されるリンクをサポートします。
Note that [RFC6119] prohibits the use of TLV 139 when it is possible to use TLV 138.
なお、[RFC6119]はTLV139を使用することが可能な場合にTLV139の使用を禁止することに注意してください。
Two new codepoints are defined to support Application-Specific Link Attribute (ASLA) advertisements:
2つの新しいコードポイントは、アプリケーション固有のリンク属性（ASLA）広告をサポートするために定義されています。
1) Application-Specific Link Attributes sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 (defined in Section 4.2).
1）TLV 22,23,25,141,222、および223のためのアプリケーション固有リンク属性（セクション4.2で定義）。
2) Application-Specific Shared Risk Link Group (SRLG) TLV (defined in Section 4.3).
2）アプリケーション固有の共有リスクリンクグループ（SRLG）TLV（セクション4.3で定義）。
To support these new advertisements, an application identifier bit mask is defined to identify the application(s) associated with a given advertisement (defined in Section 4.1).
これらの新しい広告をサポートするために、アプリケーション識別子ビットマスクは、特定の広告に関連付けられているアプリケーションを識別するために定義されています（セクション4.1で定義）。
In addition to supporting the advertisement of link attributes used by standardized applications, link attributes can also be advertised for use by user-defined applications. Such applications are not subject to standardization and are outside the scope of this document.
標準化されたアプリケーションによって使用されるリンク属性の広告をサポートすることに加えて、リンク属性はユーザー定義のアプリケーションで使用するためにアドバタイズすることもできます。そのようなアプリケーションは標準化の影響を受けず、この文書の範囲外です。
The following sections define the format of these new advertisements.
次のセクションでは、これらの新しいアドバタイズメントのフォーマットを定義します。
Identification of the set of applications associated with link attribute advertisements utilizes two bit masks. One bit mask is for standard applications where the definition of each bit is defined in a new IANA-controlled registry (see Section 7.4). A second bit mask is for non-standard user-defined applications (UDAs).
リンク属性広告に関連付けられているアプリケーションのセットの識別は、2ビットマスクを利用します。1ビットマスクは、各ビットの定義が新しいIANA制御レジストリで定義されている標準アプリケーション用です（セクション7.4を参照）。2番目のビットマスクは、非標準のユーザー定義アプリケーション（UDAS）用です。
The encoding defined below is used by both the Application-Specific Link Attributes sub-TLV and the Application-Specific SRLG TLV.
以下に定義されているエンコーディングは、アプリケーション固有のリンク属性サブTLVとアプリケーション固有のSRLG TLVの両方によって使用されます。
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| SABM Length + Flag | 1 octet
+--+--+--+--+--+--+--+--+
| UDABM Length + Flag | 1 octet
+--+--+--+--+--+--+--+--+
| SABM ... 0 - 8 octets
+--+--+--+--+--+--+--+--+
| UDABM ... 0 - 8 octets
+--+--+--+--+--+--+--+--+
SABM Length + Flag (1 octet): Standard Application Identifier Bit Mask Length + Flag
SABMの長さフラグ（1オクテット）：標準アプリケーション識別子ビットマスク長フラグ
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L| SABM Length |
+-+-+-+-+-+-+-+-+
L-flag: Legacy Flag. See Section 4.2 for a description of how this flag is used.
L-Flag：レガシーフラグ。このフラグをどのように使用するかについては、セクション4.2を参照してください。
SABM Length: Indicates the length in octets (0-8) of the Standard Application Identifier Bit Mask. The length SHOULD be the minimum required to send all bits that are set.
SABMの長さ：標準アプリケーション識別子ビットマスクのオクテット（0~8）の長さを示します。長さは設定されているすべてのビットを送信するのに必要な最小値になります。
UDABM Length + Flag (1 octet): User-Defined Application Identifier Bit Mask Length + Flag
UDABM長さフラグ（1オクテット）：ユーザー定義アプリケーション識別子ビットマスク長フラグ
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R| UDABM Length|
+-+-+-+-+-+-+-+-+
R: Reserved. SHOULD be transmitted as 0 and MUST be ignored on receipt.
R：予約済み。0として送信され、受信時に無視されなければなりません。
UDABM Length: Indicates the length in octets (0-8) of the User-Defined Application Identifier Bit Mask. The length SHOULD be the minimum required to send all bits that are set.
UDABM LENGTH：ユーザー定義アプリケーション識別子ビットマスクのOCTET（0~8）の長さを示します。長さは設定されているすべてのビットを送信するのに必要な最小値になります。
SABM (variable length): Standard Application Identifier Bit Mask
SABM（可変長）：標準アプリケーション識別子ビットマスク
(SABM Length * 8) bits
（SABMの長さ* 8）ビット
This field is omitted if SABM Length is 0.
SABMの長さが0の場合、このフィールドは省略されます。
0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+...
|R|S|F| ...
+-+-+-+-+-+-+-+-+...
R-bit: Set to specify RSVP-TE.
R-bit：RSVP-TEを指定するように設定します。
S-bit: Set to specify Segment Routing Policy.
Sビット：セグメントルーティングポリシーを指定するように設定します。
F-bit: Set to specify Loop-Free Alternate (LFA) (includes all LFA types).
Fビット：Loop-Free Alternate（LFA）を指定するように設定します（すべてのLFAタイプを含む）。
UDABM (variable length): User-Defined Application Identifier Bit Mask
UDABM（可変長）：ユーザー定義アプリケーション識別子ビットマスク
(UDABM Length * 8) bits
（udabm length * 8）ビット
0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+...
| ...
+-+-+-+-+-+-+-+-+...
This field is omitted if UDABM Length is 0.
UDABMの長さが0の場合、このフィールドは省略されます。
| Note: SABM/UDABM Length is arbitrarily limited to 8 octets in
| order to ensure that sufficient space is left to advertise link
| attributes without overrunning the maximum length of a sub-TLV.
Standard Application Identifier Bits are defined and sent starting with bit 0.
標準アプリケーション識別子ビットが定義され、ビット0から始めて送信されます。
User-Defined Application Identifier Bits have no relationship to Standard Application Identifier Bits and are not managed by IANA or any other standards body. It is recommended that bits be used starting with bit 0 so as to minimize the number of octets required to advertise all UDAs.
ユーザー定義のアプリケーション識別子ビットは標準のアプリケーション識別子ビットとの関係はありません.IANAやその他の標準の本体によって管理されていません。すべてのUDASをアドバタイズするのに必要なオクテットの数を最小限に抑えるために、ビット0からビットを使用することをお勧めします。
For both SABM and UDABM, the following rules apply:
SABMとUDABMの両方の場合、次の規則が適用されます。
* Undefined bits that are transmitted MUST be transmitted as 0 and MUST be ignored on receipt.
* 送信された未定義のビットは0として送信されなければならず、受信時に無視される必要があります。
* Bits that are not transmitted MUST be treated as if they are set to 0 on receipt.
* 送信されていないビットは、受信時に0に設定されているかのように扱われなければなりません。
* Bits that are not supported by an implementation MUST be ignored on receipt.
* 実装によってサポートされていないビットは受信時に無視されなければなりません。
A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined that supports specification of the applications and application-specific attribute values.
アプリケーションとアプリケーション固有の属性値の仕様をサポートするTLV22,23,25,141,222、および223のための新しいサブTLVが定義されています。
Type: 16
タイプ：16
Length: Variable (1 octet)
長さ：変数（1オクテット）
Value: Application Identifier Bit Mask (as defined in Section 4.1)
値：アプリケーション識別子ビットマスク（セクション4.1で定義されているように）
Link Attribute sub-sub-TLVs -- format matches the existing formats defined in [RFC5305], [RFC7308], and [RFC8570]
link属性sub-sub-tlvs - formatは、[RFC5305]、[RFC7308]、[RFC8570]で定義されている既存のフォーマットと一致します。
If the SABM or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire sub-TLV MUST be ignored.
アプリケーション識別子ビットマスクのSABMまたはUDABMの長さが8より大きい場合、サブTLV全体を無視する必要があります。
When the L-flag is set in the Application Identifier Bit Mask, all of the applications specified in the bit mask MUST use the legacy advertisements for the corresponding link found in TLVs 22, 23, 25, 141, 222, and 223, in TLV 138, or in TLV 139 as appropriate. Link attribute sub-sub-TLVs for the corresponding link attributes MUST NOT be advertised for the set of applications specified in the Standard or User-Defined Application Identifier Bit Masks, and all such advertisements MUST be ignored on receipt.
L-FLAGがアプリケーション識別子ビットマスクに設定されている場合、ビットマスクで指定されているすべてのアプリケーションは、TLVのTLV 22,23,25,141,222、および223にある対応するリンクのレガシアドバタイズメントを使用する必要があります。138、または必要に応じてTLV 139で。対応するリンク属性のためのリンク属性サブ-TLVは、標準またはユーザー定義のアプリケーション識別子ビットマスクで指定された一連のアプリケーションをアドバタイズしてはなりません。そのようなすべての広告は受信時に無視されなければなりません。
Multiple Application-Specific Link Attributes sub-TLVs for the same link MAY be advertised. When multiple sub-TLVs for the same link are advertised, they SHOULD advertise non-conflicting application/ attribute pairs. A conflict exists when the same application is associated with two different values for the same link attribute for a given link. In cases where conflicting values for the same application/attribute/link are advertised, the first advertisement received in the lowest-numbered LSP SHOULD be used, and subsequent advertisements of the same attribute SHOULD be ignored.
同じリンクのための複数のアプリケーション固有のリンク属性サブTLVをアドバタイズすることができる。同じリンクのための複数のサブTLVがアドバタイズされると、非競合するアプリケーション/属性ペアをアドバタイズする必要があります。同じアプリケーションが、特定のリンクに対して同じリンク属性に対して同じアプリケーションに関連付けられている場合、競合が存在します。同じアプリケーション/属性/リンクの矛盾する値がアドバタイズされている場合、最下位のLSPで受信された最初の広告を使用する必要があり、その後の同じ属性の広告は無視されるべきです。
For a given application, the setting of the L-flag MUST be the same in all sub-TLVs for a given link. In cases where this constraint is violated, the L-flag MUST be considered set for this application.
特定のアプリケーションの場合、L-Flagの設定は、特定のリンクに対してすべてのサブTLVで同じでなければなりません。この制約が違反されている場合は、このアプリケーションにL-Flagを設定する必要があります。
If link attributes are advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications, then any standard application and/or any user-defined application is permitted to use that set of link attributes so long as there is not another set of attributes advertised on that same link that is associated with a non-zero-length Application Identifier Bit Mask with a matching Application Identifier Bit set.
Link属性が標準アプリケーションとユーザー定義の両方のアプリケーションのためにゼロ長さのアプリケーション識別子ビットマスクに関連付けられている場合は、任意の標準のアプリケーションおよび/またはユーザー定義のアプリケーションが、ある限りそのセットのリンク属性のセットを使用できます。一致するアプリケーション識別子ビットセットを備えたゼロ以外のアプリケーション識別子ビットマスクに関連付けられているその同じリンクでアドバタイズされている別の属性のセットはありません。
IANA has created a new registry of sub-sub-TLVs to define the link attribute sub-sub-TLV codepoints (see Section 7.3). This document defines a sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1, except as noted below. The format of the sub-sub-TLVs matches the format of the corresponding legacy sub-TLV, and IANA has assigned the legacy sub-TLV identifier to the corresponding sub-sub-TLV.
IANAは、リンク属性サブ-SUB-TLVコードポイントを定義するためにサブサブTLVの新しいレジストリを作成しました（セクション7.3を参照）。この文書は、下記の範囲で、セクション3.1にリストされている既存のサブTLVのそれぞれのサブサブTLVを定義しています。サブサブTLVSのフォーマットは、対応する従来のサブTLVの形式と一致し、IANAは対応するサブ-TLV識別子を対応するサブ-SUB-TLVに割り当てました。
Maximum link bandwidth is an application-independent attribute of the link. When advertised using the Application-Specific Link Attributes sub-TLV, multiple values for the same link MUST NOT be advertised. This can be accomplished most efficiently by having a single advertisement for a given link where the Application Identifier Bit Mask identifies all the applications that are making use of the value for that link.
最大リンク帯域幅は、リンクのアプリケーションに依存しない属性です。アプリケーション固有のリンク属性を使用してアドバタイズされると、同じリンクに複数の値をアドバタイズしてはいけません。これは、アプリケーション識別子ビットマスクがそのリンクの値を利用しているすべてのアプリケーションを識別する所与のリンクに対して単一の広告を有することによって最も効率的に達成することができる。
It is also possible to advertise the same value for a given link multiple times with disjoint sets of applications specified in the Application Identifier Bit Mask. This is less efficient but still valid.
アプリケーション識別子ビットマスクで指定されたアプリケーションの互いに指定されたアプリケーションセットを使用して、特定のリンクに対して同じ値を複数回アドバタイズすることも可能です。これは効率が低いが、まだ有効です。
It is also possible to advertise a single advertisement with zero-length SABM and UDABM so long as the constraints discussed in Sections 4.2 and 6.2 are acceptable.
セクション4.2および6.2で説明されている制約が許容可能である限り、長さゼロのSABMおよびUDABMで単一の広告を宣伝することも可能である。
If different values for maximum link bandwidth for a given link are advertised, all values MUST be ignored.
特定のリンクの最大リンク帯域幅のための異なる値がアドバタイズされている場合は、すべての値を無視する必要があります。
Maximum reservable link bandwidth and unreserved bandwidth are attributes specific to RSVP-TE. When advertised using the Application-Specific Link Attributes sub-TLV, bits other than the RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit Mask. If an advertisement of maximum reservable link bandwidth or unreserved bandwidth is received with bits other than the RSVP-TE bit set, the advertisement MUST be ignored.
最大予約可能なリンク帯域幅と絶え間保存されていない帯域幅は、RSVP-TEに固有の属性です。アプリケーション固有のリンク属性を使用してアドバタイズされている場合、SUB-TLVはRSVP-TE（Rビット）以外のビットをアプリケーション識別子ビットマスクに設定してはいけません。最大予約可能リンク帯域幅または未絶えず帯域幅をRSVP-TEビットセット以外のビットで受信した場合、広告は無視されなければなりません。
[RFC8570] defines a number of dynamic performance metrics associated with a link. It is conceivable that such metrics could be measured specific to traffic associated with a specific application. Therefore, this document includes support for advertising these link attributes specific to a given application. However, in practice, it may well be more practical to have these metrics reflect the performance of all traffic on the link regardless of application. In such cases, advertisements for these attributes will be associated with all of the applications utilizing that link. This can be done either by explicitly specifying the applications in the Application Identifier Bit Mask or by using a zero-length Application Identifier Bit Mask.
[RFC8570]リンクに関連付けられている動的性能メトリックの数を定義します。そのような測定基準は、特定の用途に関連するトラフィックに特有の測定され得ることが考えられる。したがって、この文書には、特定のアプリケーションに固有のこれらのリンク属性を広告するためのサポートが含まれています。しかしながら、実際には、これらの測定基準をアプリケーションに関係なくリンク上のすべてのトラフィックの性能を反映させることがより実用的であるかもしれない。そのような場合、これらの属性の広告はそのリンクを利用したすべてのアプリケーションに関連付けられます。これは、アプリケーション識別子ビットマスク内のアプリケーションを明示的に指定することによって、または長さゼロのアプリケーション識別子ビットマスクを使用することによって実行できます。
A new TLV is defined to advertise application-specific SRLGs for a given link. Although similar in functionality to TLV 138 [RFC5307] and TLV 139 [RFC6119], a single TLV provides support for IPv4, IPv6, and unnumbered identifiers for a link. Unlike TLVs 138 and 139, it utilizes sub-TLVs to encode the link identifiers in order to provide the flexible formatting required to support multiple link identifier types.
新しいTLVは、特定のリンクに対してアプリケーション固有のSRLGをアドバタイズするように定義されています。TLV 138 [RFC5307]およびTLV 139 [RFC6119]の機能が似ていますが、単一のTLVはリンクのIPv4、IPv6、および不数字の識別子をサポートします。TLVS138および139とは異なり、複数のリンク識別子タイプをサポートするために必要な柔軟なフォーマットを提供するためにリンク識別子を符号化するためにサブTLVを利用する。
Type: 238
タイプ：238
Length: Number of octets in the value field (1 octet)
長さ：値フィールドのオクテット数（1オクテット）
Value: Neighbor System-ID + pseudonode ID (7 octets)
値：隣接システム-ID PSeudonode ID（7オクテット）
Application Identifier Bit Mask (as defined in Section 4.1)
アプリケーション識別子ビットマスク（セクション4.1で定義されているように）
Length of sub-TLVs (1 octet)
サブTLVの長さ（1オクテット）
Link Identifier sub-TLVs (variable)
リンク識別子サブTLVS（変数）
0 or more SRLG values (each value is 4 octets)
0以上のSRLG値（各値は4オクテット）
The following Link Identifier sub-TLVs are defined. The values chosen intentionally match the equivalent sub-TLVs from [RFC5305], [RFC5307], and [RFC6119].
次のリンク識別子サブTLVSが定義されています。選択された値は、[RFC5305]、[RFC5307]、[RFC6119]からの等価サブTLVを意図的に一致させます。
+======+=========================================+
| Type | Description |
+======+=========================================+
| 4 | Link Local/Remote Identifiers [RFC5307] |
+------+-----------------------------------------+
| 6 | IPv4 interface address [RFC5305] |
+------+-----------------------------------------+
| 8 | IPv4 neighbor address [RFC5305] |
+------+-----------------------------------------+
| 12 | IPv6 Interface Address [RFC6119] |
+------+-----------------------------------------+
| 13 | IPv6 Neighbor Address [RFC6119] |
+------+-----------------------------------------+
Table 2
表2.
At least one set of link identifiers (IPv4, IPv6, or Link Local/ Remote) MUST be present. Multiple occurrences of the same identifier type MUST NOT be present. TLVs that do not meet this requirement MUST be ignored.
少なくとも1つのリンク識別子（IPv4、IPv6、またはLink Local / Remote）が存在している必要があります。同じ識別子タイプの複数の出現箇所が存在してはいけません。この要件を満たしていないTLVは無視されなければなりません。
Multiple TLVs for the same link MAY be advertised.
同じリンクのための複数のTLVをアドバタイズすることができます。
When the L-flag is set in the Application Identifier Bit Mask, SRLG values MUST NOT be included in the TLV. Any SRLG values that are advertised MUST be ignored. Based on the link identifiers advertised, the corresponding legacy TLV (see Section 3.2) can be identified, and the SRLG values advertised in the legacy TLV MUST be used by the set of applications specified in the Application Identifier Bit Mask.
アプリケーション識別子ビットマスクにLフラグが設定されている場合、SRLG値はTLVに含めてはいけません。アドバタイズされたSRLG値は無視されなければなりません。アドバタイズされたリンク識別子に基づいて、対応する従来のTLV（セクション3.2を参照）を識別することができ、従来のTLVでアドバタイズされたSRLG値は、アプリケーション識別子ビットマスクで指定された一連のアプリケーションによって使用されなければなりません。
For a given application, the setting of the L-flag MUST be the same in all TLVs for a given link. In cases where this constraint is violated, the L-flag MUST be considered set for this application.
特定のアプリケーションの場合、L-Flagの設定は、特定のリンクのすべてのTLVで同じでなければなりません。この制約が違反されている場合は、このアプリケーションにL-Flagを設定する必要があります。
This document defines extensions to support the advertisement of application-specific link attributes.
このドキュメントは、アプリケーション固有のリンク属性の広告をサポートするための拡張機能を定義しています。
Whether the presence of link attribute advertisements for a given application indicates that the application is enabled on that link depends upon the application. Similarly, whether the absence of link attribute advertisements indicates that the application is not enabled depends upon the application.
特定のアプリケーションのリンク属性広告の存在が、そのリンク上でアプリケーションが有効になっていることを示しているかどうかはアプリケーションによって異なります。同様に、リンク属性広告の欠如がアプリケーションが有効になっていないことを示すかどうかはアプリケーションによって異なります。
In the case of RSVP-TE, the advertisement of application-specific link attributes implies that RSVP is enabled on that link. The absence of RSVP-TE application-specific link attributes in combination with the absence of legacy advertisements implies that RSVP is not enabled on that link.
RSVP-TEの場合、アプリケーション固有のリンク属性の広告は、そのリンクでRSVPが有効になっていることを意味します。従来の広告の欠如と組み合わせてRSVP-TEアプリケーション固有のリンク属性がないことは、RSVPがそのリンクで有効になっていないことを意味します。
In the case of SR Policy, the advertisement of application-specific link attributes does not indicate enablement of SR Policy on that link. The advertisements are only used to support constraints that may be applied when specifying an explicit path. SR Policy is implicitly enabled on all links that are part of the SR-enabled topology independent of the existence of link attribute advertisements.
SRポリシーの場合、アプリケーション固有のリンク属性の広告はそのリンク上のSRポリシーの有効化を示さない。広告は、明示的なパスを指定するときに適用される可能性がある制約をサポートするためにのみ使用されます。SRポリシーは、リンク属性広告の存在とは無関係に、SR対応トポロジの一部であるすべてのリンクで暗黙的に有効になっています。
In the case of LFA, the advertisement of application-specific link attributes does not indicate enablement of LFA on that link. Enablement is controlled by local configuration.
LFAの場合、アプリケーション固有のリンク属性の広告はそのリンク上のLFAの有効化を示さない。有効化はローカル構成によって制御されます。
In the future, if additional standard applications are defined to use this mechanism, the specification defining this use MUST define the relationship between application-specific link attribute advertisements and enablement for that application.
将来、このメカニズムを使用するために追加の標準アプリケーションが定義されている場合、この使用を定義する仕様は、そのアプリケーションのアプリケーション固有のリンク属性広告と有効化の間の関係を定義する必要があります。
This document allows the advertisement of application-specific link attributes with no application identifiers, i.e., both the Standard Application Identifier Bit Mask and the User-Defined Application Identifier Bit Mask are not present (see Section 4.1). This supports the use of the link attribute by any application. In the presence of an application where the advertisement of link attribute advertisements is used to infer the enablement of an application on that link (e.g., RSVP-TE), the absence of the application identifier leaves ambiguous whether that application is enabled on such a link. This needs to be considered when making use of the "any application" encoding.
この文書は、アプリケーション識別子、すなわち標準アプリケーション識別子ビットマスクおよびユーザ定義のアプリケーション識別子ビットマスクが存在しない、アプリケーション固有のリンク属性の広告を提供することを可能にする（セクション4.1を参照）。これは任意のアプリケーションによるリンク属性の使用をサポートします。リンク属性広告の広告がそのリンク上のアプリケーションの有効化を推測するためにアプリケーションの存在（例えばRSVP-TE）の存在下では、アプリケーション識別子が欠けていると、そのアプリケーションがそのようなリンクで有効になっているかどうかがあいまいなものになる。。「任意のアプリケーション」エンコーディングを利用する場合は考慮する必要があります。
This section discusses deployment considerations associated with the use of application-specific link attribute advertisements.
このセクションでは、アプリケーション固有のリンク属性広告の使用に関連した展開の考慮事項について説明します。
Bit identifiers for standard applications are defined in Section 4.1. All of the identifiers defined in this document are associated with applications that were already deployed in some networks prior to the writing of this document. Therefore, such applications have been deployed using the legacy advertisements. The standard applications defined in this document may continue to use legacy advertisements for a given link so long as at least one of the following conditions is true:
標準アプリケーションのビット識別子はセクション4.1で定義されています。この文書で定義されているすべての識別子は、このドキュメントの書き込み前にいくつかのネットワークですでに展開されていたアプリケーションに関連付けられています。したがって、そのようなアプリケーションはレガシ広告を使用して展開されています。この文書で定義されている標準アプリケーションは、次の条件のうち少なくとも1つが当てはまる限り、特定のリンクに対して従来の広告を使用し続けることがあります。
* The application is RSVP-TE.
* アプリケーションはRSVP-TEです。
* The application is SR Policy or LFA, and RSVP-TE is not deployed anywhere in the network.
* アプリケーションはSRポリシーまたはLFA、RSVP-TEはネットワーク内のどこにでもデプロイされていません。
* The application is SR Policy or LFA, RSVP-TE is deployed in the network, and both the set of links on which SR Policy and/or LFA advertisements are required and the attribute values used by SR Policy and/or LFA on all such links are fully congruent with the links and attribute values used by RSVP-TE.
* アプリケーションはSRポリシーまたはLFA、RSVP-TEがネットワークにデプロイされており、SRポリシーおよび/またはLFAの広告が必要なリンクのセットと、すべてのそのようなリンクでSRポリシーやLFAの両方のリンクが必要です。RSVP-TEが使用するリンクと属性値と完全に一致しています。
Under the conditions defined above, implementations that support the extensions defined in this document have the choice of using legacy advertisements or application-specific advertisements in support of SR Policy and/or LFA. This will require implementations to provide controls specifying which types of advertisements are to be sent and processed on receipt for these applications. Further discussion of the associated issues can be found in Section 6.3.
上記で定義された条件下では、この文書で定義されている拡張機能をサポートする実装は、SRポリシーおよび/またはLFAをサポートしてレガシ広告またはアプリケーション固有の広告を使用することを選択しています。これにより、どの種類の広告を送受信するかを指定してこれらのアプリケーションの受信時に処理されるコントロールを提供するための実装が必要になります。関連する問題についてのさらなる議論は、セクション6.3に見出すことができる。
New applications that future documents define to make use of the advertisements defined in this document MUST NOT make use of legacy advertisements. This simplifies deployment of new applications by eliminating the need to support multiple ways to advertise attributes for the new applications.
この文書で定義されている広告を利用するために将来の文書が定義されている新しいアプリケーションは、従来の広告を利用してはいけません。これにより、新しいアプリケーションの属性をアドバタイズするための複数の方法をサポートする必要性を排除することによって、新しいアプリケーションの展開が簡単になります。
Link attribute advertisements associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications are usable by any application, subject to the restrictions specified in Section 4.2. If support for a new application is introduced on any node in a network in the presence of such advertisements, these advertisements are permitted to be used by the new application. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced.
ゼロ長のアプリケーション識別子のビットマスクに関連するリンク属性広告とユーザ定義の両方のアプリケーションは、セクション4.2で指定された制限を条件として、あらゆるアプリケーションによって使用可能です。そのような広告の存在下でネットワーク内の任意のノードに新しいアプリケーションのサポートが導入された場合、これらの広告は新しいアプリケーションによって使用されることが許可されています。これが意図されているものではない場合は、新しいアプリケーションが導入される前に指定された明示的なアプリケーションの明示的なアプリケーションで既存のアドバタイズメントを再編成する必要があります。
Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the legacy advertisements listed in Section 3. Routers that do not support the extensions defined in this document will only process legacy advertisements and are likely to infer that RSVP-TE is enabled on the links for which legacy advertisements exist. It is expected that deployments using the legacy advertisements will persist for a significant period of time. Therefore, deployments using the extensions defined in this document in the presence of routers that do not support these extensions need to be able to interoperate with the use of legacy advertisements by the legacy routers. The following subsections discuss interoperability and backwards-compatibility concerns for a number of deployment scenarios.
RSVP-TE、SRポリシー、および/またはLFAの既存の展開はセクション3にリストされているレガシアドバタイズメントを利用しています。このドキュメントで定義されている拡張機能をサポートしていないルーターはレガシー広告を処理し、RSVP-TEが有効になっていることを推測する可能性があります。レガシ広告が存在するリンクについて。従来の広告を使用した展開はかなりの期間持続することが予想されます。したがって、これらの拡張機能をサポートしていないルーターの存在下でこのドキュメントで定義されている拡張子を使用する展開は、レガシールータによる従来の広告の使用と相互運用できる必要があります。次のサブセクションでは、多数の展開シナリオに関する相互運用性と下位互換性の懸念について説明します。
In cases where multiple applications are utilizing a given link, one of the applications is RSVP-TE, and all link attributes for a given link are common to the set of applications utilizing that link, interoperability is achieved by using legacy advertisements and sending application-specific advertisements with the L-flag set and no link attribute values. This avoids duplication of link attribute advertisements.
複数のアプリケーションが特定のリンクを利用している場合、アプリケーションの1つはRSVP-TEで、特定のリンクのすべてのリンク属性はそのリンクを利用したアプリケーションのセットに共通です。相互運用性は、レガシ広告を使用してアプリケーションを送信することによって相互運用性が実現されます。L-FLAGセットを使用した特定の広告とリンク属性値はありません。これにより、リンク属性広告の重複が回避されます。
In cases where one or more applications other than RSVP-TE are utilizing a given link and one or more link attribute values are not shared with RSVP-TE, it is necessary to use application-specific advertisements as defined in this document. Attributes for applications other than RSVP-TE MUST be advertised using application-specific advertisements that have the L-flag clear. In cases where some link attributes are shared with RSVP-TE, this requires duplicate advertisements for those attributes.
RSVP-TE以外の1つ以上のアプリケーションが特定のリンクを利用していて、1つまたは複数のリンク属性値がRSVP-TEと共有されていない場合は、このドキュメントで定義されているアプリケーション固有の広告を使用する必要があります。RSVP-TE以外のアプリケーションの属性は、L-FLAGがクリアされているアプリケーション固有の広告を使用してアドバタイズする必要があります。リンク属性がRSVP-TEと共有されている場合、これはそれらの属性に対する重複する広告を必要とします。
These guidelines apply to cases where RSVP-TE is not using any advertised attributes on a link and to cases where RSVP-TE is using some link attribute advertisements on the link but some link attributes cannot be shared with RSVP-TE.
これらのガイドラインは、RSVP-TEがリンク上の広告属性を使用していない場合と、RSVP-TEがリンク上のリンク属性広告を使用しているが一部のリンク属性をRSVP-TEと共有できません。
For the applications defined in this document, routers that do not support the extensions defined in this document will send and receive only legacy link attribute advertisements. So long as there is any legacy router in the network that has any of the applications enabled, all routers MUST continue to advertise link attributes using legacy advertisements. In addition, the link attribute values associated with the set of applications supported by legacy routers (RSVP-TE, SR Policy, and/or LFA) are always shared since legacy routers have no way of advertising or processing application-specific values. Once all legacy routers have been upgraded, migration from legacy advertisements to ASLA advertisements can be achieved via the following steps:
このドキュメントで定義されているアプリケーションの場合、このドキュメントで定義されている拡張機能をサポートしていないルーターは、従来のリンク属性の広告のみを送受信します。アプリケーションのいずれかのアプリケーションを有効にしているネットワーク内のレガシールータがある限り、すべてのルーターは従来の広告を使用してリンク属性をアドバタイズし続ける必要があります。さらに、レガシールータ（RSVP-TE、SRポリシー、および/またはLFA）でサポートされているアプリケーションのセットに関連付けられているリンク属性値は、レガシールータがアプリケーション固有の値を広告または処理する方法がないため、常に共有されています。すべてのレガシールータがアップグレードされると、従来の広告からASLA広告への移行は、次の手順で達成できます。
1) Send ASLA advertisements while continuing to advertise using legacy (all advertisements are then duplicated). Receiving routers continue to use legacy advertisements.
1）従来の宣伝を続けながらASLA広告を送信する（すべての広告は重複しています）。受信ルータは従来の広告を使用し続けます。
2) Enable the use of the ASLA advertisements on all routers.
2）すべてのルータでASLAアドバタイズメントを使用できるようにします。
3) Remove legacy advertisements.
3）従来の広告を削除します。
When the migration is complete, it then becomes possible to advertise incongruent values per application on a given link.
移行が完了したら、それは特定のリンク上のアプリケーションごとに不連続な値をアドバタイズすることが可能になります。
Note that the use of the L-flag is of no value in the migration.
なお、L-FLAGの使用はマイグレーションに値がないことに注意してください。
Documents defining new applications that make use of the application-specific advertisements defined in this document MUST discuss interoperability and backwards-compatibility issues that could occur in the presence of routers that do not support the new application.
この文書で定義されているアプリケーション固有の広告を利用する新しいアプリケーションを定義する文書新しいアプリケーションをサポートしていないルータの存在下で発生する可能性がある相互運用性と下位互換性の問題について説明する必要があります。
The extensions defined in this document include RSVP-TE as one of the applications. It is therefore possible, in the future, for implementations to migrate to the use of application-specific advertisements in support of RSVP-TE. This could be done in the following stepwise manner:
このドキュメントで定義されている拡張子には、RSVP-TEがアプリケーションの1つとして含まれています。したがって、将来的には、RSVP-TEをサポートしているアプリケーション固有の広告の使用に移行するための実装が可能です。これは次の段階的に行うことができます。
1) Upgrade all routers to support the extensions in this document.
1）このドキュメントの拡張機能をサポートするようにすべてのルーターをアップグレードします。
2) Advertise all legacy link attributes using ASLA advertisements with the L-flag clear and R-bit set. At this point, both legacy and application-specific advertisements are being sent.
2）L-Flag ClearおよびR-Bit Setを使用してASLAアドバタイズメントを使用してすべてのレガシーリンク属性をアドバタイズします。この時点で、レガシーとアプリケーション固有の広告の両方が送信されています。
3) Remove legacy advertisements.
3）従来の広告を削除します。
This section lists the protocol codepoint changes introduced by this document and the related updates made by IANA.
このセクションでは、この文書によって導入されたプロトコルコードポイント変更とIANAによって行われた関連アップデートについて説明します。
For the new registries defined under the "IS-IS TLV Codepoints" registry with the "Expert Review" registration procedure (see Sections 7.3 and 7.5), guidance for designated experts can be found in [RFC7370].
「Expert Review」登録手続き（セクション7.3と7.5を参照）で「IS-IS TLV CEDEPOINTS」レジストリ（See章7.3と7.5を参照）で定義されている新しいレジストリの場合、指定された専門家のガイダンスは[RFC7370]にあります。
IANA has registered the new sub-TLV defined in Section 4.2 in the "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223" registry.
IANAは、「TLVS22,23,25,141,222,223」レジストリの「SUB-TLV」にセクション4.2で定義されている新しいサブTLVを登録しました。
+======+======================+====+====+======+=====+=====+=====+
| Type | Description | 22 | 23 | 25 | 141 | 222 | 223 |
+======+======================+====+====+======+=====+=====+=====+
| 16 | Application-Specific | y | y | y(s) | y | y | y |
| | Link Attributes | | | | | | |
+------+----------------------+----+----+------+-----+-----+-----+
Table 3
表3.
IANA has registered the new TLV defined in Section 4.3 in the IS-IS "TLV Codepoints Registry".
IANAはセクション4.3で定義されている新しいTLVをIS-ISの "TLV CodePointsレジストリ"を登録しました。
+=======+===========================+=====+=====+=====+=======+
| Value | Description | IIH | LSP | SNP | Purge |
+=======+===========================+=====+=====+=====+=======+
| 238 | Application-Specific SRLG | n | y | n | n |
+-------+---------------------------+-----+-----+-----+-------+
Table 4
表4.
7.3. Sub-sub-TLV Codepoints for Application-Specific Link Attributes Registry
7.3. アプリケーション固有のリンク属性レジストリ用のサブサブTLVコードポイント
IANA has created a new registry titled "Sub-sub-TLV Codepoints for Application-Specific Link Attributes" under the "IS-IS TLV Codepoints" registry to control the assignment of sub-sub-TLV codepoints for the Application-Specific Link Attributes sub-TLV defined in Section 7.1. The registration procedure is "Expert Review" as defined in [RFC8126]. The initial contents of this registry are as follows:
IANAは、アプリケーション固有のリンク属性サブのサブサブTLVコードポイントの割り当てを制御するための「IS-IS TLV CEDEPOINTS」レジストリの「Sub-Sub-TLV CodePoints」レジストリを作成しました。-tlvはセクション7.1で定義されています。登録手順は[RFC8126]で定義されている「エキスパートレビュー」です。このレジストリの初期内容は次のとおりです。
+========+====================================+===========+
| Type | Description | Reference |
+========+====================================+===========+
| 0-2 | Unassigned | |
+--------+------------------------------------+-----------+
| 3 | Administrative group (color) | [RFC5305] |
+--------+------------------------------------+-----------+
| 4-8 | Unassigned | |
+--------+------------------------------------+-----------+
| 9 | Maximum link bandwidth | [RFC5305] |
+--------+------------------------------------+-----------+
| 10 | Maximum reservable link bandwidth | [RFC5305] |
+--------+------------------------------------+-----------+
| 11 | Unreserved bandwidth | [RFC5305] |
+--------+------------------------------------+-----------+
| 12-13 | Unassigned | |
+--------+------------------------------------+-----------+
| 14 | Extended Administrative Group | [RFC7308] |
+--------+------------------------------------+-----------+
| 15-17 | Unassigned | |
+--------+------------------------------------+-----------+
| 18 | TE Default Metric | [RFC5305] |
+--------+------------------------------------+-----------+
| 19-32 | Unassigned | |
+--------+------------------------------------+-----------+
| 33 | Unidirectional Link Delay | [RFC8570] |
+--------+------------------------------------+-----------+
| 34 | Min/Max Unidirectional Link Delay | [RFC8570] |
+--------+------------------------------------+-----------+
| 35 | Unidirectional Delay Variation | [RFC8570] |
+--------+------------------------------------+-----------+
| 36 | Unidirectional Link Loss | [RFC8570] |
+--------+------------------------------------+-----------+
| 37 | Unidirectional Residual Bandwidth | [RFC8570] |
+--------+------------------------------------+-----------+
| 38 | Unidirectional Available Bandwidth | [RFC8570] |
+--------+------------------------------------+-----------+
| 39 | Unidirectional Utilized Bandwidth | [RFC8570] |
+--------+------------------------------------+-----------+
| 40-255 | Unassigned | |
+--------+------------------------------------+-----------+
Table 5
表5.
IANA has also added the following notes to this registry:
IANAはこのレジストリに次のメモを追加しました。
Note: For future codepoints, in cases where the document that defines the encoding is different from the document that assigns the codepoint, the encoding reference MUST be to the document that defines the encoding.
注意：将来のコードポイントの場合、エンコーディングを定義する文書がCodePointを割り当てる文書とは異なる場合、エンコード参照はエンコーディングを定義する文書になければなりません。
Note: If a link attribute can be advertised both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub-sub-TLV of the Application-Specific Link Attributes sub-TLV defined in RFC 8919, then the same numerical code should be assigned to the link attribute whenever possible.
注：リンク属性をTLV 22,23,25,141,222、および223のサブTLVとしてアドバタイズできる場合、RFCで定義されているアプリケーション固有リンク属性サブTLVのサブサブTLV8919では、可能な限りリンク属性に同じ数字コードをリンク属性に割り当てる必要があります。
IANA has created a new registry titled "Link Attribute Application Identifiers" under the "Interior Gateway Protocol (IGP) Parameters" registry to control the assignment of Application Identifier Bits. The registration policy for this registry is "Expert Review" as defined in [RFC8126]. Bit definitions SHOULD be assigned such that all bits in the lowest available octet are allocated before assigning bits in the next octet. This minimizes the number of octets that will need to be transmitted. The initial contents of this registry are as follows:
IANAは、アプリケーション識別子ビットの割り当てを制御するために、「インテリアゲートウェイプロトコル（IGP）パラメータ」レジストリの下の「リンク属性アプリケーション識別子」という新しいレジストリを作成しました。このレジストリの登録ポリシーは、[RFC8126]で定義されているように「エキスパートレビュー」です。ビット定義は、次のオクテットにビットを割り当てる前に、使用可能な最小のオクテットのすべてのビットが割り当てられるように割り当てられます。これにより、送信する必要があるオクテットの数が最小限に抑えられます。このレジストリの初期内容は次のとおりです。
+=======+================================+
| Bit # | Name |
+=======+================================+
| 0 | RSVP-TE (R-bit) |
+-------+--------------------------------+
| 1 | Segment Routing Policy (S-bit) |
+-------+--------------------------------+
| 2 | Loop-Free Alternate (F-bit) |
+-------+--------------------------------+
| 3-63 | Unassigned |
+-------+--------------------------------+
Table 6
表6.
IANA has created a new registry titled "Sub-TLVs for TLV 238" under the "IS-IS TLV Codepoints" registry to control the assignment of sub-TLV types for the Application-Specific SRLG TLV. The registration procedure is "Expert Review" as defined in [RFC8126]. The initial contents of this registry are as follows:
IANAは、アプリケーション固有のSRLG TLVのサブTLVタイプの割り当てを制御するために、「IS-IS TLV CEDEPOINTS」レジストリの「SUB-TLVS用のサブTLV」レジストリを作成しました。登録手順は[RFC8126]で定義されている「エキスパートレビュー」です。このレジストリの初期内容は次のとおりです。
+========+===============================+===========+
| Value | Description | Reference |
+========+===============================+===========+
| 0-3 | Unassigned | |
+--------+-------------------------------+-----------+
| 4 | Link Local/Remote Identifiers | [RFC5307] |
+--------+-------------------------------+-----------+
| 5 | Unassigned | |
+--------+-------------------------------+-----------+
| 6 | IPv4 interface address | [RFC5305] |
+--------+-------------------------------+-----------+
| 7 | Unassigned | |
+--------+-------------------------------+-----------+
| 8 | IPv4 neighbor address | [RFC5305] |
+--------+-------------------------------+-----------+
| 9-11 | Unassigned | |
+--------+-------------------------------+-----------+
| 12 | IPv6 Interface Address | [RFC6119] |
+--------+-------------------------------+-----------+
| 13 | IPv6 Neighbor Address | [RFC6119] |
+--------+-------------------------------+-----------+
| 14-255 | Unassigned | |
+--------+-------------------------------+-----------+
Table 7
表7.
IANA has also added the following note to this registry:
IANAはこのレジストリに次のメモを追加しました。
Note: For future codepoints, in cases where the document that defines the encoding is different from the document that assigns the codepoint, the encoding reference MUST be to the document that defines the encoding.
注意：将来のコードポイントの場合、エンコーディングを定義する文書がCodePointを割り当てる文書とは異なる場合、エンコード参照はエンコーディングを定義する文書になければなりません。
Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310]. While IS-IS is deployed under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the IS-IS routing domain. In these deployments, the stronger authentication mechanisms defined in the aforementioned documents SHOULD be used.
IS-ISのセキュリティ上の懸念は[ISO10589]、[RFC5304]、[RFC5310]でアドレス指定されています。IS-ISが単一の管理ドメインの下に展開されている間、潜在的な攻撃者がIS-ISルーティングドメイン内の1つ以上のネットワークにアクセスできる展開があります。これらの展開では、前述の文書で定義されているより強い認証メカニズムを使用する必要があります。
This document defines a new way to advertise link attributes. Tampering with the information defined in this document may have an effect on applications using it, including impacting traffic engineering as discussed in [RFC8570]. As the advertisements defined in this document limit the scope to specific applications, the impact of tampering is similarly limited in scope.
このドキュメントは、リンク属性をアドバタイズするための新しい方法を定義します。この文書で定義されている情報を改ざんすることで、[RFC8570]で説明したようなトラフィックエンジニアリングに影響を与えるアプリケーションに影響を与える可能性があります。この文書で定義されている広告が範囲を特定のアプリケーションに限定するにつれて、改ざんの影響は同様に範囲で制限されています。
[ISO10589] International Organization for Standardization, "Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate System intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国際標準化のための国際機関 - システム間の電気通信および情報交換中間システムへの中間システムへの中間システムへの中間システムへのイントラドメイン内ルーティング情報交換プロトコルコネクションレスモードネットワークサービスを提供するためのプロトコル（ISO 8473）「、ISO / IEC 10589：2002年、第2版、2002年11月。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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暗号認証」、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 ASTINS Extensions」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<https：//www.rfc-editor.org/info/rfc5305>。
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.
[RFC5307] Kompella、K.、ED。そして、「一般化マルチプロトコルラベルスイッチング（GMPLS）」、RFC 5307、DOI 10.17487 / RFC5307、2008年10月、<https://ww.rfc-editor.org/ info / rfc5307>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R.、およびM. Fanto、 "Is-Is Generic Cryptographic認証"、RFC 5310、DOI 10.17487 / RFC5310、2009年2月、<https://www.rfc-editor.org/info/rfc5310>。
[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]ハリソン、J.、Berger、J.、およびM.Bartlett、「IS-IS」、RFC 6119、DOI 10.17487 / RFC6119、2011年2月、<https：//www.rfc-編集者。ORG / INFO / RFC6119>。
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)", RFC 7308, DOI 10.17487/RFC7308, July 2014, <https://www.rfc-editor.org/info/rfc7308>.
[RFC7308] OSBONE、E。、「MPLSトラフィックエンジニアリング（MPLS-TE（MPLS-TE）の「拡張管理グループ」、RFC 7308、DOI 10.17487 / RFC7308、2014年7月、<https：//www.rfc-editor.org/info/rfc7308>。
[RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, <https://www.rfc-editor.org/info/rfc7370>.
[RFC7370] Ginsberg、L.、「IS-IS TLV CodePointsレジストリ」、RFC 7370、DOI 10.17487 / RFC7370、2014年9月、<https：//www.rfc-editor.org/info/rfc7370>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>。
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8570] Ginsberg、L.、Ed。、Previdi、S.、Ed。、Giacalone、S.、Ward、D.、Drake、J.、およびQ. WU、 "IS IS IS Traffic Engineering（TE）メトリック拡張"、RFC 8570、DOI 10.17487 / RFC8570、2019年3月、<https://www.rfc-editor.org/info/rfc8570>。
[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.Svp-Te：LSPトンネルのRSVPへの拡張機能、RFC 3209、DOI10.17487 / RFC3209、2001年12月、<https：//www.rfc-editor.org/info/rfc3209>。
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <https://www.rfc-editor.org/info/rfc5286>.
[RFC5286] ATLAS、A.、ED。A. Zinin、ED。、「Loop-Fast Rerouteの基本仕様：ループフリーの代替」、RFC 5286、DOI 10.17487 / RFC5286、2008年9月、<https：//www.rfc-editor.org/info/rfc5286>。
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC7855] PREVIDI、S、ED。、FILSFILS、C、ED。、Decraene、B.、Litkowski、S.、Horneffer、M.、およびR. Shakir、ネットワーキング（Spring）問題ステートメントのソースパケットルーティングそして、要件 "、RFC 7855、DOI 10.17487 / RFC7855、2016年5月、<https：//www.rfc-editor.org/info/rfc7855>。
[SEGMENT-ROUTING] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-08, 8 July 2020, <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-08>.
[セグメントルーティング] Filsfils、C、Talaulikar、K.、Voyer、D.、Bogdanov、A.、およびP。マット、「セグメントルーティングポリシーアーキテクチャ」、進行中の作業、インターネットドラフト、ドラフト-IETF-Spring - ルーティングポリシー-08、<https：//tools.ietf.org/html/draft-ietf-spring-segment-Routing-Policy-08>。
Acknowledgements
謝辞
The authors would like to thank Eric Rosen and Acee Lindem for their careful review and content suggestions.
著者らは、慎重なレビューとコンテンツの提案のためにEric RosenとAcee Lindemに感謝します。
Authors' Addresses
著者の住所
Les Ginsberg Cisco Systems 821 Alder Drive Milpitas, CA 95035 United States of America
Les Berg Cisco Systems 821 Alder Drive Milpitas、CA 95035アメリカ合衆国
Email: ginsberg@cisco.com
Peter Psenak Cisco Systems Apollo Business Center Mlynske nivy 43 821 09 Bratislava Slovakia
Peter Psenak Cisco Systems ApolloビジネスセンターMlynske Nivy 43 821 09 Bratislava Slovakia
Email: ppsenak@cisco.com
Stefano Previdi Huawei Technologies
Stefano Previdi Huawei Technolos
Email: stefano@previdi.net
Wim Henderickx Nokia Copernicuslaan 50 2018 94089 Antwerp Belgium
WIM Henderickx Nokia Copernicuslaan 50 2018 94089 Antwerp Belgium
Email: wim.henderickx@nokia.com
John Drake Juniper Networks
John Drake Juniperネットワーク
Email: jdrake@juniper.net