[要約] RFC 9479 は、RSVP-TE デプロイメントで使用される既存のトラフィックエンジニアリング関連のリンク属性広告を拡張し、複数のアプリケーションがリンク属性を使用する場合にアプリケーション固有の値をサポートし、広告された値を使用するアプリケーションを示すことを目的としています。
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 9479 P. Psenak
Obsoletes: 8919 Cisco Systems
Category: Standards Track S. Previdi
ISSN: 2070-1721 Huawei Technologies
W. Henderickx
Nokia
J. Drake
Juniper Networks
October 2023
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 an indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements that address both of these shortcomings.
既存のトラフィックエンジニアリング関連のリンク属性広告が定義されており、RSVP-TEの展開で使用されています。元のRSVP-TEユースケースが定義されたため、リンク属性の広告を使用する追加のアプリケーション（セグメントルーティングポリシーとループフリーの代替品など）が定義されています。複数のアプリケーションがこれらのリンク属性を使用したい場合、現在の広告は特定の属性のアプリケーション固有の値をサポートしておらず、特定のリンクの広告値を使用しているアプリケーションがどのアプリケーションを使用しているかを示していません。このドキュメントでは、これらの両方の欠点に対処するリンク属性広告を紹介します。
This document obsoletes RFC 8919.
このドキュメントは、RFC 8919を廃止します。
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/rfc9479.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9479で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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. IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link
Attributes Registry
7.4. Link Attribute Application Identifiers Registry
7.5. IS-IS Sub-TLVs for Application-Specific SRLG TLV
8. Security Considerations
9. Changes to RFC 8919
10. References
10.1. Normative References
10.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]. The use of these extensions has been associated with deployments supporting TE over Multiprotocol Label Switching (MPLS) in the presence of the Resource Reservation Protocol (RSVP), more succinctly referred to as RSVP-TE [RFC3209].
交通工学をサポートする中間システム（IS-IS）プロトコルへのリンク属性の広告（RFC5305]によって導入され、[RFC5307]、[RFC6119]、[RFC7308]、および[RFC8570]によって拡張されました。。これらの拡張機能の使用は、リソース予約プロトコル（RSVP）の存在下でのマルチプロトコルラベルスイッチング（MPLS）のTEをサポートする展開に関連付けられており、より簡潔にRSVP-TE [RFC3209]と呼ばれています。
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 [RFC9256] 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）ポリシー[RFC9256]およびループフリーの代替（LFA）[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 that 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 setup failure for the path.
この曖昧さが問題を引き起こす場所の例は、RSVP-TEがリンクのサブセットでのみ有効になるネットワークです。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 SR. Included among these use cases is SR Policy, which is defined in [RFC9256]. 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のユースケースと要件について説明します。これらのユースケースには、[RFC9256]で定義されている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 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 Advertising Neighbor Information and TLVs for Shared Risk Link Group (SRLG) advertisements.
RSVP-TEをサポートするために使用される既存の広告には、TLVのサブTLVが近隣情報を広告し、共有リスクリンクグループ（SRLG）広告用のTLVが含まれます。
Sub-TLV values are defined in the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry.
サブTLV値は、「TLVS広告近隣情報のIS-ISサブTLV」レジストリで定義されています。
TLVs are defined in the "IS-IS TLV Codepoints" registry.
TLVは、「IS-IS 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
TLV 138 (GMPLS-SRLG):
TLV 138（GMPLS-SRLG）：
Supports links identified by IPv4 addresses and unnumbered links.
IPv4アドレスと番号のないリンクによって識別されるリンクをサポートします。
TLV 139 (IPv6 SRLG):
TLV 139（IPv6 SRLG）：
Supports links identified by IPv6 addresses.
IPv6アドレスによって識別されるリンクをサポートします。
Note that [RFC6119] prohibits the use of TLV 139 when it is possible to use TLV 138.
[RFC6119]は、TLV 138を使用できる場合にTLV 139の使用を禁止することに注意してください。
Two codepoints are defined to support Application-Specific Link Attribute (ASLA) advertisements:
アプリケーション固有のリンク属性（ASLA）広告をサポートするために、2つのコードポイントが定義されています。
1. Application-Specific Link Attributes sub-TLV for TLVs Advertising Neighbor Information (defined in Section 4.2).
1. アプリケーション固有のリンク属性TLVの近隣情報を広告するためのSub-TLV（セクション4.2で定義）。
2. Application-Specific SRLG TLV (defined in Section 4.3).
2. アプリケーション固有のSRLG TLV（セクション4.3で定義）。
To support these 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 (UDAs). Such applications are not subject to standardization and are outside the scope of this document.
標準化されたアプリケーションで使用されるリンク属性の広告をサポートすることに加えて、リンク属性は、ユーザー定義アプリケーション（UDA）で使用するために広告することもできます。このようなアプリケーションは標準化の対象ではなく、このドキュメントの範囲外です。
The following sections define the format of these 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 an IANA-controlled registry (see Section 7.4). A second bit mask is for non-standard UDAs.
Link属性広告に関連付けられているアプリケーションのセットの識別は、2つのビットマスクを利用します。1つのビットマスクは、各ビットの定義がIANA制御レジストリで定義される標準アプリケーション用です（セクション7.4を参照）。2番目のビットマスクは、標準以外のUDA用です。
The encoding defined below is used by both the Application-Specific Link Attributes sub-TLV and the Application-Specific SRLG TLV.
以下に定義するエンコードは、アプリケーション固有のリンク属性Sub-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):
SABM長フラグ（1オクテット）：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L| SABM Length |
+-+-+-+-+-+-+-+-+
L-flag:
l-flag：
Legacy Flag. See Section 4.2 for a description of how this flag is used.
レガシーフラグ。このフラグの使用方法の説明については、セクション4.2を参照してください。
SABM Length:
SABMの長さ：
This field 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.
このフィールドは、標準アプリケーション識別子ビットマスクのオクテット（0〜8）の長さを示します。長さは、設定されたすべてのビットを送信するために必要な最小でなければなりません。
Standard Application Identifier Bit Mask Length + Flag 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. SABM Length: This field 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.
標準アプリケーション識別子ビットマスク長フラグ0 1 2 3 4 5 6 7--------- | L |SABMの長さ|-------- L -FLAG：レガシーフラグ。このフラグの使用方法の説明については、セクション4.2を参照してください。SABMの長さ：このフィールドは、標準アプリケーション識別子ビットマスクのオクテット（0〜8）の長さを示します。長さは、設定されたすべてのビットを送信するために必要な最小でなければなりません。
UDABM Length + Flag (1 octet):
UDABM長フラグ（1オクテット）：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R| UDABM Length|
+-+-+-+-+-+-+-+-+
R:
R：
Reserved. SHOULD be transmitted as 0 and MUST be ignored on receipt.
予約済み。0として送信する必要があり、受信時に無視する必要があります。
UDABM Length:
UDABMの長さ：
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.
ユーザー定義のアプリケーション識別子ビットマスクのオクテット（0〜8）の長さを示します。長さは、設定されたすべてのビットを送信するために必要な最小でなければなりません。
User-Defined Application Identifier Bit Mask Length + Flag 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R| UDABM Length| +-+-+-+-+-+-+-+-+ R: Reserved. SHOULD be transmitted as 0 and MUST be ignored on receipt. 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.
ユーザー定義アプリケーション識別子ビットマスク長フラグ0 1 2 3 4 5 6 7--------- | r |UDABMの長さ|------- R：予約済み。0として送信する必要があり、受信時に無視する必要があります。UDABMの長さ：ユーザー定義のアプリケーション識別子ビットマスクのオクテット（0〜8）の長さを示します。長さは、設定されたすべてのビットを送信するために必要な最小でなければなりません。
SABM (variable length):
SABM（変数長）：
0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+...
|R|S|F| ...
+-+-+-+-+-+-+-+-+...
R-bit:
Rビット：
Set to specify RSVP-TE.
RSVP-TEを指定するように設定します。
S-bit:
s-bit：
Set to specify SR Policy (this is data plane independent).
SRポリシーを指定するように設定されています（これはデータプレーン独立です）。
F-bit:
f-bit：
Set to specify an LFA (includes all LFA types).
LFAを指定するように設定されています（すべてのLFAタイプを含む）。
Standard Application Identifier Bit Mask (SABM Length * 8) bits This field is omitted if SABM Length is 0. 0 1 2 3 4 5 6 7 ... +-+-+-+-+-+-+-+-+... |R|S|F| ... +-+-+-+-+-+-+-+-+... R-bit: Set to specify RSVP-TE. S-bit: Set to specify SR Policy (this is data plane independent). F-bit: Set to specify an LFA (includes all LFA types).
標準アプリケーション識別子ビットマスク（SABM長 * 8）ビットSABMの長さが0の場合、このフィールドは省略されています。 | ... -------- ... r -bit：RSVP -TEを指定するように設定します。 S-BIT：SRポリシーを指定するように設定されています（これはデータプレーン独立です）。 Fビット：LFAを指定するように設定されています（すべてのLFAタイプを含む）。
UDABM (variable length):
udabm（変数長）：
0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+...
| ...
+-+-+-+-+-+-+-+-+...
User-Defined Application Identifier Bit Mask (UDABM Length * 8) bits 0 1 2 3 4 5 6 7 ... +-+-+-+-+-+-+-+-+... | ... +-+-+-+-+-+-+-+-+... This field is omitted if UDABM Length is 0.
ユーザー定義アプリケーション識別子ビットマスク（UDABM長 * 8）ビット0 1 2 3 4 5 6 7 ... --------- ... |...------- ... 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.
注：SABM/UDABMの長さは、サブTLVの最大長をオーバーランすることなくリンク属性を宣伝するのに十分なスペースが残っていることを確認するために、8オクテットに任意に制限されています。
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またはその他の標準本文によって管理されていません。すべてのUDAを宣伝するために必要なオクテットの数を最小限に抑えるために、ビット0からビットを使用することをお勧めします。
For both the 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 sub-TLV for TLVs Advertising Neighbor Information is defined that supports specification of the applications and application-specific attribute values.
TLVS広告の近隣情報のSub-TLVが定義されており、アプリケーションの仕様とアプリケーション固有の属性値をサポートします。
Type:
タイプ：
16
16
Length:
長さ：
Variable (1 octet)
変数（1オクテット）
Value:
価値：
Application Identifier Bit Mask (as defined in Section 4.1) Link Attribute sub-sub-TLVs -- format matches the existing formats defined in [RFC5305], [RFC7308], and [RFC8570]
アプリケーション識別子ビットマスク（セクション4.1で定義されている）リンク属性サブサブ-TLVS-Formatは[RFC5305]、[RFC7308]、および[RFC8570]で定義された既存の形式と一致します。
If the SABM Length or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire sub-TLV MUST be ignored.
アプリケーション識別子ビットマスクのSABMの長さまたはUDABMの長さが8を超える場合、Sub-TLV全体を無視する必要があります。
When the SABM Length or UDABM Length is non-zero and the L-flag is NOT set, all applications specified in the bit mask MUST use the link attribute advertisements in the sub-TLV.
SABMの長さまたはUDABMの長さがゼロではなく、L-FLAGが設定されていない場合、ビットマスクで指定されたすべてのアプリケーションは、サブ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 Advertising Neighbor Information. Link attribute sub-sub-TLVs for the corresponding link attributes MUST NOT be advertised for the set of applications specified in the Standard Application Identifier Bit Mask or the User-Defined Application Identifier Bit Mask, and all such sub-sub-TLVs MUST be ignored on receipt.
アプリケーション識別子ビットマスクにL-FLAGが設定されている場合、ビットマスクで指定されたすべてのアプリケーションは、TLVS広告の近隣情報にある対応するリンクにレガシー広告を使用する必要があります。標準アプリケーション識別子ビットマスクまたはユーザー定義アプリケーション識別子ビットマスクで指定されたアプリケーションのセットに対して、対応するリンク属性のリンク属性サブサブ-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 Link State Protocol Data Unit (LSP) MUST be used, and subsequent advertisements of the same attribute MUST be ignored.
同じリンクの複数のアプリケーション固有のリンク属性サブTLVが宣伝される場合があります。同じリンクの複数のサブTLVが宣伝されている場合、非紛争のあるアプリケーション/属性ペアを宣伝する必要があります。同じアプリケーションが、特定のリンクの同じリンク属性の2つの異なる値に関連付けられている場合、競合が存在します。同じアプリケーション/属性/リンクの矛盾する値が宣伝されている場合、最低のリンク状態プロトコルデータユニット（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を設定したと見なす必要があります。
The end result of the set of rules defined above is that for a given application either the attribute values advertised in ASLA sub-sub-TLVs are used or the attribute values advertised in legacy sub-TLVs are used, but not both.
上記のルールのセットの最終結果は、特定のアプリケーションで、ASLAサブサブTLVで宣伝されている属性値が使用されるか、レガシーサブTLVで宣伝されている属性値が使用されますが、両方ではないことです。
Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and UDAs. Such link attribute advertisements MUST be used by standard applications and/or UDAs when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such link attribute advertisements MUST NOT be used.
リンク属性は、標準アプリケーションとUDAの両方のゼロ長アプリケーション識別子ビットマスクに関連付けられて宣伝される場合があります。 このようなリンク属性広告は、ゼロ以外のアプリケーション識別子ビットマスクと一致するアプリケーション識別子ビットセットを使用したリンク属性広告がない場合、標準アプリケーションおよび/またはUDAで使用する必要があります。 それ以外の場合、そのようなリンク属性広告を使用してはなりません。
IANA has created a 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は、リンク属性サブサブ-TLVコードポイントを定義するために、サブサブ-TLVのレジストリを作成しました（セクション7.3を参照）。 このドキュメントでは、以下の場合を除き、セクション3.1にリストされている既存のサブTLVのそれぞれのサブサブTLVを定義します。 サブサブ-TLVの形式は、対応するレガシーサブTLVの形式と一致し、IANAは対応するサブサブTLVにレガシーサブ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.
最大リンク帯域幅は、リンクのアプリケーションに依存しない属性です。アプリケーション固有のリンク属性Sub-TLVを使用して宣伝された場合、同じリンクの複数の値を宣伝する必要はありません。これは、アプリケーション識別子ビットマスクがそのリンクの値を利用しているすべてのアプリケーションを識別する特定のリンクに単一の広告を持つことにより、最も効率的に達成できます。
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 a zero-length SABM and UDABM so long as the constraints discussed in Sections 4.2 and 6.2 are satisfied.
セクション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 bit (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 R-bit set, the advertisement MUST be ignored.
最大予約可能なリンク帯域幅と予約されていない帯域幅は、RSVP-TEに固有の属性です。 アプリケーション固有のリンク属性Sub-TLVを使用して宣伝された場合、RSVP-TEビット（Rビット）以外のビットをアプリケーション識別子ビットマスクに設定してはなりません。 最大の予約可能なリンク帯域幅または予約されていない帯域幅の広告がRビットセット以外のビットで受信される場合、広告は無視する必要があります。
[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 by either explicitly specifying the applications in the Application Identifier Bit Mask or using a zero-length Application Identifier Bit Mask. The use of zero-length Application Identifier Bit Masks is further discussed in Section 6.2.
[RFC8570]は、リンクに関連付けられた多くの動的パフォーマンスメトリックを定義します。そのようなメトリックは、特定のアプリケーションに関連するトラフィックに固有の測定できると考えられます。したがって、このドキュメントには、特定のアプリケーションに固有のこれらのリンク属性を宣伝するためのサポートが含まれています。ただし、実際には、アプリケーションに関係なく、これらのメトリックをリンク上のすべてのトラフィックのパフォーマンスを反映させる方が、より実用的かもしれません。このような場合、これらの属性の広告は、そのリンクを使用してすべてのアプリケーションに関連付けられます。これは、アプリケーション識別子ビットマスク内のアプリケーションを明示的に指定するか、ゼロレングスアプリケーション識別子ビットマスクを使用して実行できます。ゼロ長のアプリケーション識別子ビットマスクの使用については、セクション6.2でさらに説明します。
A TLV is defined to advertise application-specific SRLGs for a given link. Although similar in functionality to TLV 138 [RFC5307] and TLV 139 [RFC6119], this 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、および非仮定識別子のサポートを提供します。TLVS 138および139とは異なり、サブTLVを使用してリンク識別子をエンコードして、複数のリンク識別子タイプをサポートするために必要な柔軟なフォーマットを提供します。
Type:
タイプ：
238
238
Length:
長さ：
Number of octets in the value field (1 octet)
値フィールドのオクテットの数（1オクテット）
Value:
価値：
Neighbor System-ID + pseudonode ID (7 octets) Application Identifier Bit Mask (as defined in Section 4.1) Length of sub-TLVs (1 octet) Link Identifier sub-TLVs (variable) 0 or more SRLG values (each value is 4 octets)
Neighbor-ID Pseudonode ID（7オクテット）アプリケーション識別子ビットマスク（セクション4.1で定義されています）サブTLVSの長さ（1オクテット）リンク識別子サブTLV（可変）0以上のSRLG値（各値は4オクテットです）
If the SABM Length or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire sub-TLV MUST be ignored.
アプリケーション識別子ビットマスクのSABMの長さまたはUDABMの長さが8を超える場合、Sub-TLV全体を無視する必要があります。
When the SABM Length or UDABM Length is non-zero and the L-flag is NOT set, all applications specified in the bit mask MUST use SRLG advertisements in the Application-Specific SRLG TLV.
SABMの長さまたはUDABMの長さがゼロではなく、L-FLAGが設定されていない場合、ビットマスクで指定されているすべてのアプリケーションは、アプリケーション固有のSRLG TLVでSRLG広告を使用する必要があります。
The following Link Identifier sub-TLVs are defined. The values chosen intentionally match the equivalent sub-TLVs from [RFC5305], [RFC5307], and [RFC6119].
次のリンク識別子サブTLVが定義されています。 選択された値は、[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
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-flagがアプリケーション識別子ビットマスクに設定されている場合、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 ASLAs.
このドキュメントでは、Aslasの広告をサポートする拡張機能を定義しています。
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.
特定のアプリケーションのリンク属性広告の存在が、そのリンクでアプリケーションが有効になっていることを示しているかどうかは、アプリケーションによって異なります。同様に、Link属性広告の不在がアプリケーションが有効になっていないことを示しているかどうかは、アプリケーションに依存します。
In the case of RSVP-TE, the advertisement of ASLAs implies that RSVP is enabled on that link. The absence of RSVP-TE ASLAs in combination with the absence of legacy advertisements implies that RSVP is not enabled on that link.
RSVP-TEの場合、ASLASの広告は、RSVPがそのリンクで有効になっていることを暗示しています。RSVP-TE Aslasがレガシー広告がないことと組み合わせていないことは、RSVPがそのリンクで有効になっていないことを意味します。
In the case of SR Policy, the advertisement of ASLAs 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ポリシーの場合、Aslasの広告は、そのリンク上のSRポリシーの有効化を示していません。広告は、明示的なパスを指定するときに適用できる制約をサポートするためにのみ使用されます。SRポリシーは、Link属性広告の存在とは無関係にSR対応トポロジの一部であるすべてのリンクで暗黙的に有効になっています。
In the case of LFA, the advertisement of ASLAs does not indicate enablement of LFA on that link. Enablement is controlled by local configuration.
LFAの場合、Aslasの広告は、そのリンク上のLFAの有効化を示していません。イネーブルメントはローカル構成によって制御されます。
In the future, if additional standard applications are defined to use this mechanism, the specification defining this use MUST define the relationship between ASLA advertisements and enablement for those applications.
将来的には、このメカニズムを使用するために追加の標準アプリケーションが定義されている場合、この使用を定義する仕様は、それらのアプリケーションのASLA広告と有効化との関係を定義する必要があります。
This document allows the advertisement of ASLAs with no application identifiers, i.e., neither the Standard Application Identifier Bit Mask nor the User-Defined Application Identifier Bit Mask is 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 attributes 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.
このドキュメントでは、アプリケーション識別子のないASLAの広告、つまり、標準のアプリケーション識別子ビットマスクもユーザー定義のアプリケーション識別子ビットマスクも存在しません（セクション4.1を参照）。これにより、アプリケーションによるリンク属性の使用がサポートされます。リンク属性の広告を使用してそのリンク上のアプリケーションの有効化（RSVP-TEなど）を推測するアプリケーションが存在する場合、アプリケーション識別子がないため、そのアプリケーションがそのようなリンクで有効になっているかどうかを曖昧にします。これは、「任意のアプリケーション」エンコーディングを使用するときに考慮する必要があります。
This section discusses deployment considerations associated with the use of ASLA advertisements.
このセクションでは、ASLA広告の使用に関連する展開に関する考慮事項について説明します。
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 UDAs 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, the new application will use these advertisements, when the aforementioned restrictions are met. If this is not what is intended, then existing link attribute advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced.
セクション4.2で指定された制限を条件として、標準アプリケーションとUDAの両方のゼロ長さのアプリケーション識別子識別子ビットマスクに関連付けられているリンク属性識別子識別子識別子ビットマスクは、任意のアプリケーションで使用可能です。このような広告の存在下でネットワーク内の任意のノードに新しいアプリケーションのサポートが導入された場合、新しいアプリケーションは、前述の制限が満たされたときにこれらの広告を使用します。これが意図されていない場合は、新しいアプリケーションが導入される前に指定された明示的なアプリケーションセットで既存のリンク属性広告を読み取る必要があります。
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セットとリンク属性値なしの特定の広告。これにより、Link属性広告の複製が回避されます。
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 standard 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. In addition, the link attribute values associated with these applications are always shared, since legacy routers have no way of advertising or processing application-specific values. So long as there is any legacy router in the network that has any of the standard applications defined in this document enabled, all routers MUST continue to advertise link attributes for these applications using only legacy advertisements. ASLA advertisements for these applications MUST NOT be sent. Once all legacy routers have been upgraded, migration from legacy advertisements to ASLA advertisements can be achieved via the following steps:
このドキュメントで定義されている標準アプリケーションの場合、このドキュメントで定義されている拡張機能をサポートしていないルーターは、レガシーリンク属性の広告のみを送信および受信します。さらに、レガシールーターにはアプリケーション固有の値を広告または処理する方法がないため、これらのアプリケーションに関連付けられたリンク属性値は常に共有されます。ネットワークにレガシールーターがある限り、このドキュメントを有効にしている標準アプリケーションのいずれかを備えた標準アプリケーションを備えている限り、すべてのルーターはレガシー広告のみを使用してこれらのアプリケーションのリンク属性を引き続き宣伝する必要があります。これらのアプリケーションのASLA広告を送信してはなりません。すべてのレガシールーターがアップグレードされたら、レガシー広告からASLA広告への移行を次の手順で達成できます。
1. Send ASLA advertisements while continuing to advertise legacy advertisements (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 the R-bit set. At this point, both legacy and application-specific advertisements are being sent.
2. l-flag Clearとrビットセットを使用して、ASLA広告を使用してすべてのレガシーリンク属性を宣伝します。この時点で、レガシーとアプリケーション固有の広告の両方が送信されています。
3. Remove legacy advertisements.
3. レガシー広告を削除します。
This section lists the protocol codepoint changes introduced by this document and the related IANA updates.
このセクションには、このドキュメントによって導入されたプロトコルコードポイントの変更と関連するIANAの更新をリストします。
For the registries defined under the "IS-IS TLV Codepoints" group of registries with a registration procedure of "Expert Review" (see Sections 7.3 and 7.5), guidance for designated experts can be found in [RFC7370].
「IS-IS TLV CODEPOINTS」のレジストリグループの下で定義されているレジストリについては、「専門家のレビュー」の登録手順（セクション7.3および7.5を参照）を備えているため、指定された専門家のガイダンスは[RFC7370]に記載されています。
Note that in all cases where the registry reference was to RFC 8919, the registry has been updated to refer to this document.
レジストリの参照がRFC 8919への参照があったすべての場合、レジストリが更新されてこのドキュメントを参照していることに注意してください。
IANA has registered the sub-TLV defined in Section 4.2 in the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry.
IANAは、セクション4.2で「IS-IS Sub-TLVSの近隣情報のSub-TLV」で定義されているSub-TLVを登録しました。レジストリ。
+======+======================+====+====+======+=====+=====+=====+
| Type | Description | 22 | 23 | 25 | 141 | 222 | 223 |
+======+======================+====+====+======+=====+=====+=====+
| 16 | Application-Specific | y | y | y(s) | y | y | y |
| | Link Attributes | | | | | | |
+------+----------------------+----+----+------+-----+-----+-----+
Table 3
IANA has registered the TLV defined in Section 4.3 in the "IS-IS Top-Level TLV Codepoints" registry.
IANAは、セクション4.3で「IS-ISトップレベルのTLVコードポイント」レジストリで定義されているTLVを登録しています。
+=======+===========================+=====+=====+=====+=======+
| Value | Description | IIH | LSP | SNP | Purge |
+=======+===========================+=====+=====+=====+=======+
| 238 | Application-Specific SRLG | n | y | n | n |
+-------+---------------------------+-----+-----+-----+-------+
Table 4
IANA has created a registry titled "IS-IS 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は、「IS-IS TLV CODEPOINTS」レジストリの下にある「IS-IS Sub-Sub-TLV CODEPOINTS」というタイトルのレジストリを作成しました。属性セクション7.1で定義されているSub-TLV。登録手順は、[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
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 advertising neighbor information and as a sub-sub-TLV of the Application-Specific Link Attributes sub-TLV defined in RFC 9479, then the same numerical code should be assigned to the link attribute whenever possible.
注：リンク属性を、近隣情報を広告するTLVS広告のサブTLVとして、およびRFC 9479で定義されたアプリケーション固有のリンク属性のサブサブTLVとして宣伝できる場合、同じ数値コードは可能な場合はいつでもリンク属性に割り当てられます。
IANA has created a registry titled "Link Attribute Application Identifiers" within the "Interior Gateway Protocol (IGP) Parameters" group of registries 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は、「Interior Gateway Protocol（IGP）パラメーター」レジストリのグループ内に「Link属性アプリケーション識別子」というタイトルのレジストリを作成し、アプリケーション識別子ビットの割り当てを制御します。このレジストリの登録ポリシーは、[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
IANA has created a registry titled "IS-IS Sub-TLVs for Application-Specific SRLG TLV" under the "IS-IS TLV Codepoints" registry to control the assignment of sub-TLV types for the Application-Specific SRLG TLV (TLV 238). The registration procedure is "Expert Review" as defined in [RFC8126]. The initial contents of this registry are as follows:
IANAは、「IS-IS TLVコードポイント」レジストリの下で「アプリケーション固有のSRLG TLVのIS-ISサブ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
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 an improved way to advertise link attributes. Tampering with the information defined in this document may have an effect on applications using it, including impacting TE 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]で説明されているTEに影響を与えるなど、アプリケーションを使用したアプリケーションに影響を与える可能性があります。このドキュメントで定義されている広告が特定のアプリケーションに範囲を制限するため、改ざんの影響も同様に範囲が制限されています。
Discussion within the LSR WG indicated that there was confusion regarding the use of ASLA advertisements that had a zero-length SABM/ UDABM. The discussion can be seen by searching the LSR WG mailing list archives for the thread "Proposed Errata for RFCs 8919/8920" starting on 15 June 2021.
LSR WG内での議論は、ゼロ長さのSABM/ UDABMを持つASLA広告の使用に関して混乱があったことを示しました。この議論は、2021年6月15日から始まるスレッド「RFCS 8919/8920の提案されたErrata」のLSR WGメーリングリストアーカイブを検索することで見ることができます。
Changes to Sections 4.2, 4.3, and 6.2 have been introduced to clarify normative behavior in the presence of such advertisements. In particular, the text in [RFC8919] used the word "permitted", suggesting that the use of such advertisements is "optional". Such an interpretation could lead to interoperability issues and is not what was intended.
セクション4.2、4.3、および6.2の変更が導入され、そのような広告の存在下で規範的な行動を明確にしています。特に、[RFC8919]のテキストは「許可された」という言葉を使用し、そのような広告の使用が「オプション」であることを示唆しています。このような解釈は、相互運用性の問題につながる可能性があり、意図されたものではありません。
The replacement text makes explicit the specific conditions when such advertisements MUST be used and the specific conditions under which they MUST NOT be used.
交換テキストは、そのような広告を使用する必要がある場合、およびそれらを使用してはならない特定の条件を明示的にします。
[ISO10589] ISO, "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)", Second Edition, ISO/IEC 10589:2002, November 2002,
<https://www.iso.org/standard/30932.html>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS Application-Specific Link Attributes",
RFC 8919, DOI 10.17487/RFC8919, October 2020,
<https://www.rfc-editor.org/info/rfc8919>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
RFC 8919 included the following acknowledgements:
RFC 8919には、次の謝辞が含まれています。
Eric Rosen and Acee Lindem for their careful review and content suggestions.
慎重なレビューとコンテンツの提案について、エリック・ローゼンとエイシー・リンデム。
For the new version (this document), the authors would like to thank Bruno Decraene.
新しいバージョン（このドキュメント）については、著者はBruno Decraeneに感謝したいと思います。
Les Ginsberg
Cisco Systems
United States of America
Email: ginsberg@cisco.com
Peter Psenak
Cisco Systems
Slovakia
Email: ppsenak@cisco.com
Stefano Previdi
Huawei Technologies
Email: stefano@previdi.net
Wim Henderickx
Nokia
Copernicuslaan 50
2018 94089 Antwerp
Belgium
Email: wim.henderickx@nokia.com
John Drake
Juniper Networks
Email: jdrake@juniper.net