[要約] RFC 9492 は、OSPFアプリケーション固有のリンク属性を広告するために、既存のトラフィックエンジニアリング関連のリンク属性広告を拡張し、複数のアプリケーションがリンク属性を使用する場合に対応することを目的としています。
Internet Engineering Task Force (IETF) P. Psenak, Ed.
Request for Comments: 9492 L. Ginsberg
Obsoletes: 8920 Cisco Systems
Category: Standards Track W. Henderickx
ISSN: 2070-1721 Nokia
J. Tantsura
Nvidia
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 such as Segment Routing (SR) Policy and Loop-Free Alternates (LFAs) 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 link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings.
既存のトラフィックエンジニアリング関連のリンク属性広告が定義されており、RSVP-TEの展開で使用されています。元のRSVP-TEユースケースが定義されたため、リンク属性広告を使用するセグメントルーティング（SR）ポリシーやループフリーの代替（LFA）などの追加のアプリケーションが定義されています。複数のアプリケーションがこれらのリンク属性を使用したい場合、現在の広告は特定の属性のアプリケーション固有の値をサポートしておらず、特定のリンクの広告値を使用しているアプリケーションの表示もサポートしていません。このドキュメントでは、これらの両方の欠点に対処するOSPFV2とOSPFV3のリンク属性広告を紹介します。
This document obsoletes RFC 8920.
このドキュメントは、RFC 8920を廃止します。
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/rfc9492.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9492で取得できます。
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. Existing Advertisement of Link Attributes
4. Advertisement of Link Attributes
4.1. OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA
5. Advertisement of Application-Specific Values
6. Reused TE Link Attributes
6.1. Shared Risk Link Group (SRLG)
6.2. Extended Metrics
6.3. Administrative Group
6.4. TE Metric
7. Maximum Link Bandwidth
8. Considerations for Extended TE Metrics
9. Local Interface IPv6 Address Sub-TLV
10. Remote Interface IPv6 Address Sub-TLV
11. Attribute Advertisements and Enablement
12. Deployment Considerations
12.1. Use of Legacy RSVP-TE LSA Advertisements
12.2. Use of Zero-Length Application Identifier Bit Masks
12.3. Interoperability, Backwards Compatibility, and Migration
Concerns
12.3.1. Multiple Applications: Common Attributes with RSVP-TE
12.3.2. Multiple Applications: Some Attributes Not Shared with
RSVP-TE
12.3.3. Interoperability with Legacy Routers
12.3.4. Use of Application-Specific Advertisements for RSVP-TE
13. Security Considerations
14. IANA Considerations
14.1. OSPFv2
14.2. OSPFv3
15. Changes to RFC 8920
16. References
16.1. Normative References
16.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
Advertisement of link attributes by the OSPFv2 [RFC2328] and OSPFv3 [RFC5340] protocols in support of traffic engineering (TE) was introduced by [RFC3630] and [RFC5329], respectively. It has been extended by [RFC4203], [RFC7308], and [RFC7471]. 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].
トラフィックエンジニアリング（TE）をサポートするOSPFV2 [RFC2328]およびOSPFV3 [RFC5340]プロトコルによるリンク属性の広告は、それぞれ[RFC3630]および[RFC5329]によって導入されました。[RFC4203]、[RFC7308]、および[RFC7471]によって拡張されました。これらの拡張機能の使用は、リソース予約プロトコル（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 5.
このドキュメントの目的のために、アプリケーションはリンク属性広告を使用するテクノロジーであり、その例はセクション5にリストされています。
In recent years, new applications have been introduced that have use cases for many of the link attributes historically used by RSVP-TE. Such applications include SR Policy [RFC9256] and 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]および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 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 for 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 OSPF, it is only necessary to discuss use cases that justify the key points identified in the introduction, which are:
前述のように、リンク属性のユースケースの進化は続くと予想されます。したがって、既存のユースケースの議論は、この執筆時点で知られている要件に限定されています。ただし、OSPFに既に存在するものを超えて必要な機能を決定するためには、導入で特定された重要なポイントを正当化するユースケースを議論する必要があります。
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.
最後に、単一の属性値を複数のアプリケーション間で共有できる多くのケースがまだある可能性があるため、ソリューションは、可能な限り広告の複製リンク/属性ペアを最小限に抑える必要があります。
There are existing advertisements used in support of RSVP-TE. These advertisements are carried in the OSPFv2 TE Opaque Link State Advertisement (LSA) [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329]. Additional RSVP-TE link attributes have been defined by [RFC4203], [RFC7308], and [RFC7471].
RSVP-TEをサポートするために使用される既存の広告があります。これらの広告は、OSPFV2 TE Opaque Link State Advertisement（LSA）[RFC3630]およびOSPFV3 Intra-AREA-TE-LSA [RFC5329]に掲載されています。追加のRSVP-TEリンク属性は、[RFC4203]、[RFC7308]、および[RFC7471]によって定義されています。
Extended Link Opaque LSAs as defined in [RFC7684] for OSPFv2 and E-Router-LSAs [RFC8362] for OSPFv3 are used to advertise link attributes that are used by applications other than RSVP-TE or GMPLS [RFC4203]. These LSAs were defined as generic containers for distribution of the extended link attributes.
OSPFV2およびE-Router-LSAS [RFC8362]の[RFC7684]で定義されている拡張リンク不透明LSAは、RSVP-TEまたはGMPLS [RFC4203]以外のアプリケーションで使用されるリンク属性を宣伝するために使用されます。これらのLSAは、拡張リンク属性の分布のための一般的な容器として定義されました。
This section outlines the solution for advertising link attributes originally defined for RSVP-TE or GMPLS when they are used for other applications.
このセクションでは、RSVP-TEまたはGMPLが他のアプリケーションに使用されたときに元々定義された広告リンク属性のソリューションの概要を説明します。
The following are the advantages of Extended Link Opaque LSAs as defined in [RFC7684] for OSPFv2 and E-Router-LSAs [RFC8362] for OSPFv3 with respect to the advertisement of link attributes originally defined for RSVP-TE when used in packet networks and in GMPLS:
以下は、パケットネットワークで使用された場合、およびRSVP-TEに対して元々定義されたリンク属性の広告に関して、OSPFV2およびE-Router-LSAS [RFC8362]の[RFC7684]およびE-Router-LSAS [RFC8362]の[RFC7684]で定義されている拡張リンク不透明LSAの利点です。GMPLS：
1. Advertisement of the link attributes does not make the link part of the RSVP-TE topology. It avoids any conflicts and is fully compatible with [RFC3630] and [RFC5329].
1. リンク属性の広告は、RSVP-TEトポロジのリンクの一部ではありません。競合を回避し、[RFC3630]および[RFC5329]と完全に互換性があります。
2. The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA remain truly opaque to OSPFv2 and OSPFv3 as originally defined in [RFC3630] and [RFC5329], respectively. Their contents are not inspected by OSPF, which instead acts as a pure transport.
2. OSPFV2 TE OPAQUE LSAおよびOSPFV3 Intra-AREA-TE-LSAは、それぞれ[RFC3630]および[RFC5329]でそれぞれ定義されているように、OSPFV2およびOSPFV3にそれぞれ真に不透明であり続けます。それらの内容は、代わりに純粋な輸送として機能するOSPFによって検査されません。
3. There is a clear distinction between link attributes used by RSVP-TE and link attributes used by other OSPFv2 or OSPFv3 applications.
3. RSVP-TEで使用されるリンク属性と、他のOSPFV2またはOSPFV3アプリケーションで使用されるリンク属性との間には明確な区別があります。
4. All link attributes that are used by other applications are advertised in the Extended Link Opaque LSA in OSPFv2 [RFC7684] or the OSPFv3 E-Router-LSA [RFC8362] in OSPFv3.
4. 他のアプリケーションで使用されるすべてのリンク属性は、OSPFV2 [RFC7684]の拡張リンク不透明LSAまたはOSPFV3のOSPFV3 E-Router-LSA [RFC8362]に宣伝されています。
The disadvantage of this approach is that in rare cases, the same link attribute is advertised in both the TE Opaque and Extended Link Attribute LSAs in OSPFv2 or the Intra-Area-TE-LSA and E-Router-LSA in OSPFv3.
このアプローチの欠点は、まれに、OSPFV2のTEオパークおよび拡張リンク属性LSAまたはOSPFV3のE-Router-LSAの両方で同じリンク属性が宣伝されていることです。
The Extended Link Opaque LSA [RFC7684] and E-Router-LSA [RFC8362] are used to advertise any link attributes used for non-RSVP-TE applications in OSPFv2 or OSPFv3, respectively, including those that have been originally defined for RSVP-TE applications (see Section 6).
拡張リンク不透明LSA [RFC7684]およびEルーターLSA [RFC8362]を使用して、RSVP-TEで元々定義されたものを含め、OSPFv2またはOSPFV3の非RSVP-TEアプリケーションにそれぞれ使用されるリンク属性をそれぞれ宣伝するために使用されます。アプリケーション（セクション6を参照）。
TE link attributes used for RSVP-TE/GMPLS continue to use the OSPFv2 TE Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329].
RSVP-TE/GMPLSに使用されるTEリンク属性は、OSPFV2 TE OPAQUE LSA [RFC3630]およびOSPFV3 Intra-AREA-TE-LSA [RFC5329]を引き続き使用しています。
The format of the link attribute TLVs that have been defined for RSVP-TE applications will be kept unchanged even when they are used for non-RSVP-TE applications. Unique codepoints are allocated for these link attribute TLVs from the "OSPFv2 Extended Link TLV Sub-TLVs" registry [RFC7684] and from the "OSPFv3 Extended-LSA Sub-TLVs" registry [RFC8362], as specified in Section 14.
RSVP-TEアプリケーション用に定義されているリンク属性TLVの形式は、非RSVP-TEアプリケーションに使用されている場合でも変更されません。一意のコードポイントは、これらのリンク属性TLVに「OSPFV2拡張リンクTLVサブTLVS」レジストリ[RFC7684]およびセクション14で指定されている「OSPFV3拡張LSAサブTLVS」レジストリ[RFC8362]から割り当てられます。
To allow advertisement of the application-specific values of the link attribute, an Application-Specific Link Attributes (ASLA) sub-TLV is defined. The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended Link TLV [RFC7684] and OSPFv3 Router-Link TLV [RFC8362].
リンク属性のアプリケーション固有の値の広告を許可するために、アプリケーション固有のリンク属性（ASLA）Sub-TLVが定義されています。ASLA SUB-TLVは、OSPFV2拡張リンクTLV [RFC7684]およびOSPFV3ルーターリンクTLV [RFC8362]のサブTLVです。
In addition to advertising the link attributes for standardized applications, link attributes can be advertised for the purpose of applications that are not standardized. We call such an application a "user-defined application" or "UDA". These applications are not subject to standardization and are outside of the scope of this specification.
標準化されたアプリケーションのリンク属性を宣伝することに加えて、標準化されていないアプリケーションを目的としてリンク属性を宣伝できます。このようなアプリケーションを「ユーザー定義アプリケーション」または「UDA」と呼びます。これらのアプリケーションは標準化の対象ではなく、この仕様の範囲外です。
The ASLA sub-TLV is an optional sub-TLV of the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. Multiple ASLA sub-TLVs can be present in a parent TLV when different applications want to control different link attributes or when a different value of the same attribute needs to be advertised by multiple applications. The ASLA sub-TLV MUST be used for advertisement of the link attributes listed at the end of this section if these are advertised inside the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. It has the following format:
ASLA Sub-TLVは、OSPFV2拡張リンクTLVおよびOSPFV3ルーターリンクTLVのオプションのサブTLVです。異なるアプリケーションが異なるリンク属性を制御したい場合、または同じ属性の異なる値を複数のアプリケーションで宣伝する必要がある場合、複数のASLAサブTLVが親TLVに存在する可能性があります。ASLA Sub-TLVは、これらがOSPFV2拡張リンクTLVおよびOSPFV3 Router-Link TLV内に宣伝されている場合、このセクションの最後にリストされているリンク属性の広告に使用する必要があります。次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SABM Length | UDABM Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Standard Application Identifier Bit Mask (SABM) |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-Defined Application Identifier Bit Mask (UDABM) |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Attribute sub-TLVs |
+- -+
| ... |
where:
ただし：
Type:
タイプ：
10 (OSPFv2), 11 (OSPFv3)
10（OSPFV2）、11（OSPFV3）
Length:
長さ：
Variable
変数
SABM Length:
SABMの長さ：
Standard Application Identifier Bit Mask Length in octets. The value MUST be 0, 4, or 8. If the Standard Application Identifier Bit Mask is not present, the SABM Length MUST be set to 0.
オクテットの標準アプリケーション識別子ビットマスク長。値は0、4、または8でなければなりません。標準のアプリケーション識別子ビットマスクが存在しない場合、SABMの長さは0に設定する必要があります。
UDABM Length:
UDABMの長さ：
User-Defined Application Identifier Bit Mask Length in octets. The value MUST be 0, 4, or 8. If the User-Defined Application Identifier Bit Mask is not present, the UDABM Length MUST be set to 0.
オクテットのユーザー定義アプリケーション識別子ビットマスク長。値は0、4、または8でなければなりません。ユーザー定義のアプリケーション識別子ビットマスクが存在しない場合、UDABMの長さは0に設定する必要があります。
Standard Application Identifier Bit Mask:
標準アプリケーション識別子ビットマスク：
0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+...
|R|S|F| ...
+-+-+-+-+-+-+-+-+...
Bit 0 (R-bit):
ビット0（r-bit）：
RSVP-TE.
RSVP-TE。
Bit 1 (S-bit):
ビット1（s-bit）：
SR Policy (this is data plane independent).
SRポリシー（これはデータプレーン独立です）。
Bit 2 (F-bit):
ビット2（f-bit）：
Loop-Free Alternate (includes all LFA types).
ループフリーの代替（すべてのLFAタイプを含む）。
Optional set of bits, where each bit represents a single standard application. Bits are defined in the "Link Attribute Application Identifiers" registry, which is defined in [RFC9479]. Current assignments are repeated here for informational purposes: 0 1 2 3 4 5 6 7 ... +-+-+-+-+-+-+-+-+... |R|S|F| ... +-+-+-+-+-+-+-+-+... Bit 0 (R-bit): RSVP-TE. Bit 1 (S-bit): SR Policy (this is data plane independent). Bit 2 (F-bit): Loop-Free Alternate (includes all LFA types).
各ビットが単一の標準アプリケーションを表すオプションのビットセット。ビットは、[RFC9479]で定義されている「リンク属性アプリケーション識別子」レジストリで定義されます。現在の割り当ては、情報提供のためにここで繰り返されます：0 1 2 3 4 5 6 7 ... -------- ... | r | s | f |... -------- ...ビット0（r -bit）：rsvp -te。ビット1（s-bit）：SRポリシー（これはデータプレーン独立です）。ビット2（f-bit）：ループフリーの代替（すべてのLFAタイプを含む）。
User-Defined Application Identifier Bit Mask:
ユーザー定義のアプリケーション識別子ビットマスク：
Optional set of bits, where each bit represents a single user-defined application.
各ビットが単一のユーザー定義アプリケーションを表すオプションのビットセット。
If the SABM or UDABM Length is other than 0, 4, or 8, the ASLA sub-TLV MUST be ignored by the receiver.
SABMまたはUDABMの長さが0、4、または8以外の場合、ASLA SUB-TLVはレシーバーによって無視する必要があります。
Standard Application Identifier Bits are defined and sent starting with bit 0. Undefined bits that are transmitted MUST be transmitted as 0 and MUST be ignored on receipt. Bits that are not transmitted MUST be treated as if they are set to 0 on receipt. Bits that are not supported by an implementation MUST be ignored on receipt.
標準のアプリケーション識別子ビットは定義され、ビット0から送信されます。送信される未定義のビットは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 these bits be used starting with bit 0 so as to minimize the number of octets required to advertise all UDAs. Undefined bits that are transmitted MUST be transmitted as 0 and MUST be ignored on receipt. Bits that are not transmitted MUST be treated as if they are set to 0 on receipt. Bits that are not supported by an implementation MUST be ignored on receipt.
ユーザー定義のアプリケーション識別子ビットは、標準のアプリケーション識別子ビットとの関係がなく、IANAまたはその他の標準本文によって管理されていません。これらのビットは、すべてのUDAを宣伝するために必要なオクテットの数を最小限に抑えるために、ビット0で開始することをお勧めします。送信される未定義のビットは0として送信する必要があり、受領時に無視する必要があります。送信されないビットは、領収書で0に設定されているかのように扱う必要があります。実装によってサポートされていないビットは、受領時に無視する必要があります。
If the link attribute advertisement is intended to be only used by a specific set of applications, corresponding bit masks MUST be present and one or more application-specific bits MUST be set for all applications that use the link attributes advertised in the ASLA sub-TLV.
リンク属性広告が特定のアプリケーションセットによってのみ使用されることを目的としている場合、対応するビットマスクが存在する必要があり、ASLA Sub-TLVで宣伝されているリンク属性を使用するすべてのアプリケーションに1つ以上のアプリケーション固有のビットを設定する必要があります。
Application Identifier Bit Masks apply to all link attributes that support application-specific values and are advertised in the ASLA sub-TLV.
アプリケーション識別子ビットマスクは、アプリケーション固有の値をサポートし、ASLAサブTLVで宣伝されているすべてのリンク属性に適用されます。
The advantage of not making the Application Identifier Bit Masks part of the attribute advertisement itself is that the format of any previously defined link attributes can be kept and reused when advertising them in the ASLA sub-TLV.
アプリケーション識別子ビットマスクを属性広告自体の一部にしないという利点は、ASLAサブTLVでそれらを宣伝するときに、以前に定義されたリンク属性の形式を保持および再利用できることです。
If the same attribute is advertised in more than one ASLA sub-TLV with the application listed in the Application Identifier Bit Masks, the application SHOULD use the first instance of advertisement and ignore any subsequent advertisements of that attribute.
同じ属性がアプリケーション識別子ビットマスクにリストされているアプリケーションを使用して複数のASLAサブTLVで宣伝されている場合、アプリケーションは広告の最初のインスタンスを使用し、その属性の後続の広告を無視する必要があります。
Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such link attribute advertisements MUST be used by standard applications and/or user-defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present. Otherwise, such link attribute advertisements MUST NOT be used.
リンク属性は、標準アプリケーションとユーザー定義アプリケーションの両方のゼロ長アプリケーション識別子ビットマスクに関連付けられて宣伝される場合があります。このようなリンク属性広告は、ゼロ以外のアプリケーション識別子ビットマスクと一致するアプリケーション識別子ビットセットを使用したリンク属性広告がない場合、標準アプリケーションおよび/またはユーザー定義アプリケーションで使用する必要があります。それ以外の場合、そのようなリンク属性広告を使用してはなりません。
This document defines the initial set of link attributes that MUST use the ASLA sub-TLV if advertised in the OSPFv2 Extended Link TLV or in the OSPFv3 Router-Link TLV. Documents that define new link attributes MUST state whether the new attributes support application-specific values and, as such, are advertised in an ASLA sub-TLV. The standard link attributes that are advertised in ASLA sub-TLVs are:
このドキュメントでは、OSPFV2拡張リンクTLVまたはOSPFV3ルーターリンクTLVで宣伝されている場合、ASLA Sub-TLVを使用する必要があるリンク属性の初期セットを定義します。新しいリンク属性を定義するドキュメントは、新しい属性がアプリケーション固有の値をサポートし、そのためASLAサブTLVで宣伝されているかどうかを述べる必要があります。ASLAサブTLVで宣伝されている標準のリンク属性は次のとおりです。
* Shared Risk Link Group [RFC4203]
* 共有リスクリンクグループ[RFC4203]
* Unidirectional Link Delay [RFC7471]
* 単方向リンク遅延[RFC7471]
* Min/Max Unidirectional Link Delay [RFC7471]
* Min/Max単方向リンク遅延[RFC7471]
* Unidirectional Delay Variation [RFC7471]
* 単方向遅延変動[RFC7471]
* Unidirectional Link Loss [RFC7471]
* 単方向リンク損失[RFC7471]
* Unidirectional Residual Bandwidth [RFC7471]
* 一方向の残留帯域幅[RFC7471]
* Unidirectional Available Bandwidth [RFC7471]
* 単方向利用可能な帯域幅[RFC7471]
* Unidirectional Utilized Bandwidth [RFC7471]
* 単方向利用帯域幅[RFC7471]
* Administrative Group [RFC3630]
* 管理グループ[RFC3630]
* Extended Administrative Group [RFC7308]
* 拡張管理グループ[RFC7308]
* TE Metric [RFC3630]
* TEメトリック[RFC3630]
This section defines the use case and indicates the codepoints (Section 14) from the "OSPFv2 Extended Link TLV Sub-TLVs" registry and "OSPFv3 Extended-LSA Sub-TLVs" registry for some of the link attributes that have been originally defined for RSVP-TE or GMPLS.
このセクションでは、ユースケースを定義し、「OSPFV2拡張リンクTLVサブTLV」レジストリと「OSPFV3拡張LSAサブTLVS」レジストリのコードポイント（セクション14）を示しています。-teまたはgmpls。
The SRLG of a link can be used in OSPF-calculated IPFRR (IP Fast Reroute) [RFC5714] to compute a backup path that does not share any SRLG with the protected link.
リンクのSRLGは、OSPFで計算されたIPFRR（IP Fast Reroute）[RFC5714]で使用して、保護されたリンクとSRLGを共有しないバックアップパスを計算できます。
To advertise the SRLG of the link in the OSPFv2 Extended Link TLV, the same format for the sub-TLV defined in Section 1.3 of [RFC4203] is used with TLV type 11. Similarly, for OSPFv3 to advertise the SRLG in the OSPFv3 Router-Link TLV, TLV type 12 is used.
OSPFV2拡張リンクTLVのリンクのSRLGを宣伝するために、[RFC4203]のセクション1.3で定義されているサブTLVの同じ形式をTLVタイプ11で使用します。同様に、OSPFV3のsrlgを宣伝するために、OSPFV3 router-のSRLGを宣伝するために使用されます。リンクTLV、TLVタイプ12が使用されます。
[RFC3630] defines several link bandwidth types. [RFC7471] defines extended link metrics that are based on link bandwidth, delay, and loss characteristics. All of these can be used to compute primary and backup paths within an OSPF area to satisfy requirements for bandwidth, delay (nominal or worst case), or loss.
[RFC3630]は、いくつかのリンク帯域幅タイプを定義します。[RFC7471]は、リンク帯域幅、遅延、および損失特性に基づいた拡張リンクメトリックを定義します。これらすべてを使用して、OSPF領域内のプライマリおよびバックアップパスを計算して、帯域幅、遅延（名目または最悪の場合）、または損失の要件を満たすことができます。
To advertise extended link metrics in the OSPFv2 Extended Link TLV, the same format for the sub-TLVs defined in [RFC7471] is used with the following TLV types:
OSPFV2拡張リンクTLVに拡張リンクメトリックを宣伝するために、[RFC7471]で定義されたサブTLVの同じ形式が次のTLVタイプで使用されます。
12:
12：
Unidirectional Link Delay
単方向リンク遅延
13:
13：
Min/Max Unidirectional Link Delay
Min/Max単方向リンク遅延
14:
14：
Unidirectional Delay Variation
単方向遅延変動
15:
15：
Unidirectional Link Loss
単方向リンク損失
16:
16：
Unidirectional Residual Bandwidth
一方向の残留帯域幅
17:
17：
Unidirectional Available Bandwidth
単方向利用可能な帯域幅
18:
18：
Unidirectional Utilized Bandwidth
単方向利用帯域幅
To advertise extended link metrics in the Router-Link TLV inside the OSPFv3 E-Router-LSA, the same format for the sub-TLVs defined in [RFC7471] is used with the following TLV types:
OSPFV3 E-Router-LSA内のルーターリンクTLVの拡張リンクメトリックを宣伝するには、[RFC7471]で定義されたサブTLVの同じ形式が次のTLVタイプで使用されます。
13:
13：
Unidirectional Link Delay
単方向リンク遅延
14:
14：
Min/Max Unidirectional Link Delay
Min/Max単方向リンク遅延
15:
15：
Unidirectional Delay Variation
単方向遅延変動
16:
16：
Unidirectional Link Loss
単方向リンク損失
17:
17：
Unidirectional Residual Bandwidth
一方向の残留帯域幅
18:
18：
Unidirectional Available Bandwidth
単方向利用可能な帯域幅
19:
19：
Unidirectional Utilized Bandwidth
単方向利用帯域幅
[RFC3630] and [RFC7308] define the Administrative Group and Extended Administrative Group sub-TLVs, respectively.
[RFC3630]および[RFC7308]は、それぞれ管理グループと拡張管理グループのサブTLVを定義します。
To advertise the Administrative Group and Extended Administrative Group in the OSPFv2 Extended Link TLV, the same format for the sub-TLVs defined in [RFC3630] and [RFC7308] is used with the following TLV types:
OSPFV2拡張リンクTLVの管理グループと拡張管理グループを宣伝するには、[RFC3630]および[RFC7308]で定義されているサブTLVの同じ形式を次のTLVタイプで使用します。
19:
19：
Administrative Group
管理グループ
20:
20：
Extended Administrative Group
拡張管理グループ
To advertise the Administrative Group and Extended Administrative Group in the OSPFv3 Router-Link TLV, the same format for the sub-TLVs defined in [RFC3630] and [RFC7308] is used with the following TLV types:
OSPFV3ルーターリンクTLVの管理グループと拡張管理グループを宣伝するために、[RFC3630]および[RFC7308]で定義されたサブTLVの同じ形式を次のTLVタイプで使用します。
20:
20：
Administrative Group
管理グループ
21:
21：
Extended Administrative Group
拡張管理グループ
[RFC3630] defines the TE Metric.
[RFC3630]はTEメトリックを定義します。
To advertise the TE Metric in the OSPFv2 Extended Link TLV, the same format for the sub-TLV defined in Section 2.5.5 of [RFC3630] is used with TLV type 22. Similarly, for OSPFv3 to advertise the TE Metric in the OSPFv3 Router-Link TLV, TLV type 22 is used.
OSPFV2拡張リンクTLVのTEメトリックを宣伝するために、[RFC3630]のセクション2.5.5で定義されているサブTLVの同じ形式をTLVタイプ22で使用します。同様に、OSOSPFV3がOSOSPFV3ルーターのTEメトリックを宣伝するために使用されます。-Link TLV、TLVタイプ22が使用されます。
Maximum link bandwidth is an application-independent attribute of the link that is defined in [RFC3630]. Because it is an application-independent attribute, it MUST NOT be advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a sub-TLV of the Extended Link TLV in the Extended Link Opaque LSA in OSPFv2 [RFC7684] or as a sub-TLV of the Router-Link TLV in the E-Router-LSA Router-Link TLV in OSPFv3 [RFC8362].
最大リンク帯域幅は、[RFC3630]で定義されているリンクのアプリケーションに依存しない属性です。アプリケーションに依存しない属性であるため、ASLAサブTLVで宣伝してはなりません。代わりに、OSPFv2 [RFC7684]の拡張リンク不透明LSAの拡張リンクTLVのサブTLVとして、またはE-Router-LSA Router-Link TLVのルーターリンクTLVのサブTLVとして宣伝される場合があります。OSPFV3 [RFC8362]。
To advertise the maximum link bandwidth in the OSPFv2 Extended Link TLV, the same format for the sub-TLV defined in [RFC3630] is used with TLV type 23.
OSPFV2拡張リンクTLVの最大リンク帯域幅を宣伝するために、[RFC3630]で定義されたサブTLVの同じ形式がTLV型23で使用されます。
To advertise the maximum link bandwidth in the OSPFv3 Router-Link TLV, the same format for the sub-TLV defined in [RFC3630] is used with TLV type 23.
OSPFV3ルーターリンクTLVの最大リンク帯域幅を宣伝するために、[RFC3630]で定義されたサブTLVの同じ形式をTLV型23で使用します。
[RFC7471] 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 can 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. The use of zero-length Application Identifier Bit Mask is further discussed in Section 12.2.
[RFC7471]は、リンクに関連付けられた多くの動的パフォーマンスメトリックを定義します。そのようなメトリックは、特定のアプリケーションに関連するトラフィックに固有の測定できると考えられます。したがって、このドキュメントには、特定のアプリケーションに固有のこれらのリンク属性を宣伝するためのサポートが含まれています。ただし、実際には、アプリケーションに関係なく、これらのメトリックをリンク上のすべてのトラフィックのパフォーマンスを反映させる方が、より実用的かもしれません。そのような場合、これらの属性の広告は、そのリンクを使用してすべてのアプリケーションに関連付けられます。これは、アプリケーション識別子ビットマスク内のアプリケーションを明示的に指定するか、ゼロレングスアプリケーション識別子ビットマスクを使用することにより、実行できます。ゼロレングスのアプリケーション識別子ビットマスクの使用については、セクション12.2でさらに説明します。
The Local Interface IPv6 Address sub-TLV is an application-independent attribute of the link that is defined in [RFC5329]. Because it is an application-independent attribute, it MUST NOT be advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA [RFC8362].
ローカルインターフェイスIPv6アドレスSub-TLVは、[RFC5329]で定義されているリンクのアプリケーションに依存しない属性です。アプリケーションに依存しない属性であるため、ASLAサブTLVで宣伝してはなりません。代わりに、OSPFV3 E-Router-LSA [RFC8362]内のルーターリンクTLVのサブTLVとして宣伝される場合があります。
To advertise the Local Interface IPv6 Address sub-TLV in the OSPFv3 Router-Link TLV, the same format for the sub-TLV defined in [RFC5329] is used with TLV type 24.
OSPFV3ルーターリンクTLVのローカルインターフェイスIPv6アドレスSub-TLVを宣伝するために、[RFC5329]で定義されたSub-TLVの同じ形式がTLVタイプ24で使用されます。
The Remote Interface IPv6 Address sub-TLV is an application-independent attribute of the link that is defined in [RFC5329]. Because it is an application-independent attribute, it MUST NOT be advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA [RFC8362].
リモートインターフェイスIPv6アドレスSub-TLVは、[RFC5329]で定義されているリンクのアプリケーションに依存しない属性です。アプリケーションに依存しない属性であるため、ASLAサブTLVで宣伝してはなりません。代わりに、OSPFV3 E-Router-LSA [RFC8362]内のルーターリンクTLVのサブTLVとして宣伝される場合があります。
To advertise the Remote Interface IPv6 Address sub-TLV in the OSPFv3 Router-Link TLV, the same format for the sub-TLV defined in [RFC5329] is used with TLV type 25.
OSPFV3ルーターリンクTLVのリモートインターフェイスIPv6アドレスSUB-TLVを宣伝するために、[RFC5329]で定義されたSub-TLVの同じ形式がTLVタイプ25で使用されます。
This document defines extensions to support the advertisement of application-specific link attributes.
このドキュメントでは、アプリケーション固有のリンク属性の広告をサポートする拡張機能を定義します。
There are applications where the application enablement on the link is relevant; for example, with RSVP-TE, one needs to make sure that RSVP is enabled on the link before sending an RSVP-TE signaling message over it.
リンク上のアプリケーションを有効にするアプリケーションが関連しています。たとえば、RSVP-TEを使用すると、RSVP-TEシグナリングメッセージを送信する前に、RSVPがリンクで有効になっていることを確認する必要があります。
There are applications where the enablement of the application on the link is irrelevant and has nothing to do with the fact that some link attributes are advertised for the purpose of such application. An example of this is LFA.
リンク上のアプリケーションの有効化が無関係であり、そのようなアプリケーションの目的のためにいくつかのリンク属性が宣伝されているという事実とは何の関係もないアプリケーションがあります。この例はLFAです。
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 application-specific link attributes has no implication of RSVP-TE being enabled on that link. The RSVP-TE enablement is solely derived from the information carried in the OSPFv2 TE Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329].
RSVP-TEの場合、アプリケーション固有のリンク属性の広告は、そのリンクでRSVP-TEが有効になっているという意味はありません。RSVP-TEイネーブルメントは、OSPFV2 TE OPAQUE LSA [RFC3630]およびOSPFV3 Intra-AREA-TE-LSA [RFC5329]にある情報からのみ派生しています。
In the case of SR Policy, advertisement of application-specific link attributes does not indicate enablement of SR Policy. 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ポリシーは、Link属性広告の存在とは無関係に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 SABM and the UDABM are not present (see Section 5). 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.
このドキュメントにより、アプリケーション識別子なしのアプリケーション固有のリンク属性の広告が可能になります。つまり、SABMとUDABMの両方が存在しません（セクション5を参照）。これにより、アプリケーションによるリンク属性の使用がサポートされます。リンク属性の広告を使用してそのリンク上のアプリケーションの有効化（RSVP-TEなど）を推測するアプリケーションが存在する場合、アプリケーション識別子がないため、そのアプリケーションがそのようなリンクで有効になっているかどうかを曖昧にします。これは、「任意のアプリケーション」エンコーディングを使用するときに考慮する必要があります。
Bit identifiers for standard applications are defined in Section 5. 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 RSVP-TE LSA advertisements. The standard applications defined in this document may continue to use RSVP-TE LSA advertisements for a given link so long as at least one of the following conditions is true:
標準アプリケーションのビット識別子はセクション5で定義されています。このドキュメントで定義されているすべての識別子は、このドキュメントの執筆前にいくつかのネットワークに既に展開されているアプリケーションに関連付けられています。したがって、このようなアプリケーションは、RSVP-TE LSA広告を使用して展開されています。このドキュメントで定義されている標準アプリケーションは、次の条件の少なくとも1つが真である限り、特定のリンクに対してRSVP-TE LSA広告を引き続き使用できます。
* 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 RSVP-TE LSA 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 12.3.
上記の条件下では、このドキュメントで定義されている拡張機能をサポートする実装では、SRポリシーおよび/またはLFAをサポートするためにRSVP-TE LSA広告またはアプリケーション固有の広告を使用する選択があります。これには、これらのアプリケーションの受領時に送信および処理される広告の種類を指定するコントロールを提供するための実装が必要です。関連する問題のさらなる議論は、セクション12.3にあります。
New applications that future documents define to make use of the advertisements defined in this document MUST NOT make use of RSVP-TE LSA advertisements. This simplifies deployment of new applications by eliminating the need to support multiple ways to advertise attributes for the new applications.
将来のドキュメントが定義する新しいアプリケーションは、このドキュメントで定義されている広告を使用して、RSVP-TE LSA広告を使用してはなりません。これにより、新しいアプリケーションの属性を宣伝する複数の方法をサポートする必要性を排除することにより、新しいアプリケーションの展開が簡素化されます。
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 5. 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.
標準アプリケーションとユーザー定義アプリケーションの両方のゼロレングスアプリケーション識別子識別子ビットマスクに関連付けられているリンク属性広告は、セクション5で指定された制限を条件として、任意のアプリケーションで使用できます。このような広告が存在する場合、新しいアプリケーションは、前述の制限が満たされたときにこれらの広告を使用します。これが意図されていない場合は、新しいアプリケーションが導入される前に指定された明示的なアプリケーションセットで既存のリンク属性広告を読み取る必要があります。
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 for RSVP-TE. Attributes for applications other than RSVP-TE MUST be advertised using application-specific advertisements. This results in duplicate advertisements for those attributes.
複数のアプリケーションが特定のリンクを利用している場合、アプリケーションの1つはRSVP-TEであり、特定のリンクのすべてのリンク属性は、そのリンクを利用するアプリケーションのセットに共通しています。。RSVP-TE以外のアプリケーションの属性は、アプリケーション固有の広告を使用して宣伝する必要があります。これにより、これらの属性の広告が重複します。
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, interoperability is achieved by using legacy advertisements for RSVP-TE. Attributes for applications other than RSVP-TE MUST be advertised using application-specific advertisements. 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のレガシー広告を使用することにより相互運用性が達成されます。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 new application-specific advertisements while continuing to advertise using the legacy advertisement (all advertisements are then duplicated). Receiving routers continue to use legacy advertisements.
1) レガシー広告を使用して広告を継続しながら、新しいアプリケーション固有の広告を送信します（すべての広告が複製されます）。ルーターの受信は、レガシー広告を引き続き使用しています。
2) Enable the use of the application-specific advertisements on all routers.
2) すべてのルーターでアプリケーション固有の広告を使用できるようにします。
3) Keep legacy advertisements if needed for RSVP-TE purposes.
3) RSVP-TEの目的で必要に応じて、レガシー広告を保持します。
When the migration is complete, it then becomes possible to advertise incongruent values per application on a given link.
移行が完了すると、特定のリンクでアプリケーションごとに一致しない値を宣伝することが可能になります。
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 support RSVP-TE as one of the supported applications. It is, however, RECOMMENDED to advertise all link attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329] to maintain backwards compatibility. RSVP-TE can eventually utilize the application-specific advertisements for newly defined link attributes that are defined as application specific.
このドキュメントで定義されている拡張機能は、サポートされているアプリケーションの1つとしてRSVP-TEをサポートしています。ただし、既存のOSPFV2 TE Opaque LSA [RFC3630]およびOSPFV3 Intra-AREA-TE-LSA [RFC5329]のRSVP-TEのすべてのリンク属性を逆方向の適合性を維持することをお勧めします。RSVP-TEは、アプリケーション固有として定義される新たに定義されたリンク属性のアプリケーション固有の広告を最終的に利用できます。
Link attributes that are not allowed to be advertised in the ASLA sub-TLV, such as maximum reservable link bandwidth and unreserved bandwidth, MUST use the OSPFv2 TE Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329] and MUST NOT be advertised in the ASLA sub-TLV.
ASLAサブTLVで宣伝されないリンク属性は、最大予約可能なリンク帯域幅や予約されていない帯域幅など、OSPFV2 TE OPAQUE LSA [RFC3630]およびOSPFV3 Intra-AREA-TE-LSA [RFC5329]を使用し、必須でなければなりません。ASLAサブTLVで宣伝されていません。
Existing security extensions as described in [RFC2328], [RFC5340], and [RFC8362] apply to extensions defined in this document. While OSPF is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPF routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC5709], [RFC7474], [RFC4552], or [RFC7166] SHOULD be used.
[RFC2328]、[RFC5340]、および[RFC8362]で説明されている既存のセキュリティ拡張機能は、このドキュメントで定義されている拡張機能に適用されます。OSPFは単一の管理ドメインの下にありますが、潜在的な攻撃者がOSPFルーティングドメインの1つ以上のネットワークにアクセスできる展開があります。これらの展開では、[RFC5709]、[RFC7474]、[RFC4552]、または[RFC7166]で指定されているものなど、より強力な認証メカニズムを使用する必要があります。
Implementations must ensure that if any of the TLVs and sub-TLVs defined in this document are malformed, they are detected and do not facilitate a vulnerability for attackers to crash or otherwise compromise the OSPF router or routing process. Reception of a malformed TLV or sub-TLV SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and sub-TLVs SHOULD be rate-limited to prevent a denial-of-service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane.
実装は、このドキュメントで定義されているTLVとサブTLVのいずれかが奇形である場合、それらが検出され、攻撃者がOSPFルーターまたはルーティングプロセスをクラッシュさせたり、侵害する脆弱性を促進しないことを保証する必要があります。不正なTLVまたはSub-TLVの受信は、さらに分析するためにカウントおよび/またはログに記録する必要があります。奇形のTLVとサブTLVの伐採は、OSPFコントロールプレーンのオーバーロードを防ぐために、サービス拒否（DOS）攻撃（DOS）攻撃（分散またはその他）を防ぐために料金制限する必要があります。
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, which uses various link attributes for its path computation. This is similar in nature to the impacts associated with, for example, [RFC3630]. As the advertisements defined in this document limit the scope to specific applications, the impact of tampering is similarly limited in scope.
このドキュメントは、リンク属性を宣伝する改善された方法を定義しています。このドキュメントで定義されている情報を改ざんすると、PATH計算にさまざまなリンク属性を使用するTEに影響を与えるなど、アプリケーションを使用するアプリケーションに影響を与える可能性があります。これは、たとえば[RFC3630]に関連する影響と本質的に類似しています。このドキュメントで定義されている広告が特定のアプリケーションに範囲を制限するため、改ざんの影響も同様に範囲が制限されています。
This specification updates two existing registries:
この仕様は、2つの既存のレジストリを更新します。
* the "OSPFv2 Extended Link TLV Sub-TLVs" registry
* 「OSPFV2拡張リンクTLV Sub-TLVS」レジストリ
* the "OSPFv3 Extended-LSA Sub-TLVs" registry
* 「OSPFV3拡張LSAサブTLVS」レジストリ
The values defined in this document have been allocated using the IETF Review procedure as described in [RFC8126].
このドキュメントで定義されている値は、[RFC8126]で説明されているIETFレビュー手順を使用して割り当てられています。
The "OSPFv2 Extended Link TLV Sub-TLVs" registry [RFC7684] defines sub-TLVs at any level of nesting for OSPFv2 Extended Link TLVs. IANA has assigned the following sub-TLV types in the "OSPFv2 Extended Link TLV Sub-TLVs" registry:
「OSPFV2拡張リンクTLV Sub-TLVS」レジストリ[RFC7684]は、OSPFV2拡張リンクTLVの任意のレベルのネストでサブTLVを定義します。IANAは、「OSPFV2拡張リンクTLV SUB-TLVS」レジストリに次のサブTLVタイプを割り当てました。
10:
10：
Application-Specific Link Attributes
アプリケーション固有のリンク属性
11:
11：
Shared Risk Link Group
共有リスクリンクグループ
12:
12：
Unidirectional Link Delay
単方向リンク遅延
13:
13：
Min/Max Unidirectional Link Delay
Min/Max単方向リンク遅延
14:
14：
Unidirectional Delay Variation
単方向遅延変動
15:
15：
Unidirectional Link Loss
単方向リンク損失
16:
16：
Unidirectional Residual Bandwidth
一方向の残留帯域幅
17:
17：
Unidirectional Available Bandwidth
単方向利用可能な帯域幅
18:
18：
Unidirectional Utilized Bandwidth
単方向利用帯域幅
19:
19：
Administrative Group
管理グループ
20:
20：
Extended Administrative Group
拡張管理グループ
22:
22：
TE Metric
TEメトリック
23:
23：
Maximum link bandwidth
最大リンク帯域幅
The "OSPFv3 Extended-LSA Sub-TLVs" registry [RFC8362] defines sub-TLVs at any level of nesting for OSPFv3 Extended LSAs. IANA has assigned the following sub-TLV types in the "OSPFv3 Extended-LSA Sub-TLVs" registry:
「OSPFV3拡張LSAサブTLVS」レジストリ[RFC8362]は、OSPFV3拡張LSAの任意のレベルのネスティングでサブTLVを定義します。IANAは、「OSPFV3 Extended-LSA Sub-TLVS」レジストリに次のサブTLVタイプを割り当てました。
11:
11：
Application-Specific Link Attributes
アプリケーション固有のリンク属性
12:
12：
Shared Risk Link Group
共有リスクリンクグループ
13:
13：
Unidirectional Link Delay
単方向リンク遅延
14:
14：
Min/Max Unidirectional Link Delay
Min/Max単方向リンク遅延
15:
15：
Unidirectional Delay Variation
単方向遅延変動
16:
16：
Unidirectional Link Loss
単方向リンク損失
17:
17：
Unidirectional Residual Bandwidth
一方向の残留帯域幅
18:
18：
Unidirectional Available Bandwidth
単方向利用可能な帯域幅
19:
19：
Unidirectional Utilized Bandwidth
単方向利用帯域幅
20:
20：
Administrative Group
管理グループ
21:
21：
Extended Administrative Group
拡張管理グループ
22:
22：
TE Metric
TEメトリック
23:
23：
Maximum link bandwidth
最大リンク帯域幅
24:
24：
Local Interface IPv6 Address
ローカルインターフェイスIPv6アドレス
25:
25：
Remote Interface IPv6 Address
リモートインターフェイスIPv6アドレス
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 Section 5 have been introduced to clarify normative behavior in the presence of such advertisements. [RFC8920] defines advertising link attributes with zero-length SABM and zero-length UDABM as a means of advertising link attributes that can be used by any application. However, the text uses 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.
このような広告の存在下で規範的な行動を明確にするために、セクション5の変更が導入されました。[RFC8920]は、あらゆるアプリケーションで使用できる広告リンク属性の手段として、ゼロ長SABMおよびゼロ長のUDABMを持つ広告リンク属性を定義します。ただし、テキストは「許可された」という言葉を使用しており、そのような広告の使用が「オプション」であることを示唆しています。このような解釈は、相互運用性の問題につながる可能性があり、意図されたものではありません。
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.
交換テキストは、そのような広告を使用する必要がある場合、およびそれらを使用してはならない特定の条件を明示的にします。
A subsection discussing the use of zero-length Application Identifier Bit Masks has been added for greater consistency with [RFC9479]. See Section 12.2.
[RFC9479]との一貫性を高めるために、ゼロ長さのアプリケーション識別子ビットマスクの使用について議論するサブセクションが追加されました。セクション12.2を参照してください。
[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>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[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>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[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>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC9479] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS Application-Specific Link Attributes",
RFC 9479, DOI 10.17487/RFC9479, October 2023,
<https://www.rfc-editor.org/info/rfc9479>.
[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>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>.
[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>.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, DOI 10.17487/RFC5709, October
2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014,
<https://www.rfc-editor.org/info/rfc7166>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>.
[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>.
[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>.
[RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura,
J., and J. Drake, "OSPF Application-Specific Link
Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020,
<https://www.rfc-editor.org/info/rfc8920>.
[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>.
The following acknowledgments are included in [RFC8920]:
次の謝辞は[RFC8920]に含まれています。
Thanks to Chris Bowers for his review and comments.
彼のレビューとコメントをしてくれたクリス・バウアーズに感謝します。
Thanks to Alvaro Retana for his detailed review and comments.
彼の詳細なレビューとコメントをしてくれたAlvaro Retanaに感謝します。
For this document, the authors would like to thank Bruno Decraene.
この文書については、著者はBruno Decraeneに感謝したいと思います。
The following people contributed to the content of this document and should be considered as coauthors:
次の人々はこの文書の内容に貢献し、共著者と見なされるべきです。
Acee Lindem
LabN Consulting, L.L.C.
United States of America
Email: acee.ietf@gmail.com
Ketan Talaulikar
Cisco Systems
India
Email: ketant.ietf@gmail.com
Hannes Gredler
RtBrick Inc.
Email: hannes@rtbrick.com
Peter Psenak (editor)
Cisco Systems
Slovakia
Email: ppsenak@cisco.com
Les Ginsberg
Cisco Systems
United States of America
Email: ginsberg@cisco.com
Wim Henderickx
Nokia
Copernicuslaan 50
2018 94089 Antwerp
Belgium
Email: wim.henderickx@nokia.com
Jeff Tantsura
Nvidia
United States of America
Email: jefftant.ietf@gmail.com
John Drake
Juniper Networks
United States of America
Email: jdrake@juniper.net