[要約] RFC 7752は、BGPを使用してリンク状態とトラフィックエンジニアリング（TE）情報を上位に配布するための仕様です。このRFCの目的は、BGPを使用してネットワークの状態情報を効果的に共有し、ネットワークのパフォーマンスと効率を向上させることです。
Internet Engineering Task Force (IETF) H. Gredler, Ed.
Request for Comments: 7752 Individual Contributor
Category: Standards Track J. Medved
ISSN: 2070-1721 S. Previdi
Cisco Systems, Inc.
A. Farrel
Juniper Networks, Inc.
S. Ray
March 2016
North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
BGPを使用したリンクステートおよびトラフィックエンジニアリング（TE）情報のノースバウンド配信
Abstract
概要
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
多くの環境では、ネットワークトポロジーと、トラフィックエンジニアリング（TE）情報を含むネットワーク内の接続の現在の状態に基づいて計算を実行するために、ネットワーク外部のコンポーネントが要求されます。これは通常、ネットワーク内のIGPルーティングプロトコルによって配布される情報です。
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.
このドキュメントでは、リンク状態とTEの情報をネットワークから収集し、BGPルーティングプロトコルを使用して外部コンポーネントと共有できるメカニズムについて説明します。これは、新しいBGPネットワーク層到達可能性情報（NLRI）エンコード形式を使用して実現されます。このメカニズムは、物理および仮想IGPリンクに適用できます。説明されているメカニズムはポリシー制御の対象です。
Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).
この手法のアプリケーションには、アプリケーション層トラフィック最適化（ALTO）サーバーおよびパス計算要素（PCE）が含まれます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7752.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7752で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. Motivation and Applicability ....................................5
2.1. MPLS-TE with PCE ...........................................5
2.2. ALTO Server Network API ....................................6
3. Carrying Link-State Information in BGP ..........................7
3.1. TLV Format .................................................8
3.2. The Link-State NLRI ........................................8
3.2.1. Node Descriptors ...................................12
3.2.2. Link Descriptors ...................................16
3.2.3. Prefix Descriptors .................................18
3.3. The BGP-LS Attribute ......................................19
3.3.1. Node Attribute TLVs ................................20
3.3.2. Link Attribute TLVs ................................23
3.3.3. Prefix Attribute TLVs ..............................28
3.4. BGP Next-Hop Information ..................................31
3.5. Inter-AS Links ............................................32
3.6. Router-ID Anchoring Example: ISO Pseudonode ...............32
3.7. Router-ID Anchoring Example: OSPF Pseudonode ..............33
3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration ....34
4. Link to Path Aggregation .......................................34
4.1. Example: No Link Aggregation ..............................35
4.2. Example: ASBR to ASBR Path Aggregation ....................35
4.3. Example: Multi-AS Path Aggregation ........................36
5. IANA Considerations ............................................36
5.1. Guidance for Designated Experts ...........................37
6. Manageability Considerations ...................................38
6.1. Operational Considerations ................................38
6.1.1. Operations .........................................38
6.1.2. Installation and Initial Setup .....................38
6.1.3. Migration Path .....................................38
6.1.4. Requirements on Other Protocols and
Functional Components ..............................38
6.1.5. Impact on Network Operation ........................38
6.1.6. Verifying Correct Operation ........................39
6.2. Management Considerations .................................39
6.2.1. Management Information .............................39
6.2.2. Fault Management ...................................39
6.2.3. Configuration Management ...........................40
6.2.4. Accounting Management ..............................40
6.2.5. Performance Management .............................40
6.2.6. Security Management ................................41
7. TLV/Sub-TLV Code Points Summary ................................41
8. Security Considerations ........................................42
9. References .....................................................43
9.1. Normative References ......................................43
9.2. Informative References ....................................45
Acknowledgements ..................................................47
Contributors ......................................................47
Authors' Addresses ................................................48
The contents of a Link-State Database (LSDB) or of an IGP's Traffic Engineering Database (TED) describe only the links and nodes within an IGP area. Some applications, such as end-to-end Traffic Engineering (TE), would benefit from visibility outside one area or Autonomous System (AS) in order to make better decisions.
リンク状態データベース（LSDB）またはIGPのトラフィックエンジニアリングデータベース（TED）の内容は、IGPエリア内のリンクとノードのみを記述します。エンドツーエンドのトラフィックエンジニアリング（TE）などの一部のアプリケーションでは、より適切な決定を行うために、1つのエリアまたは自律システム（AS）の外部からの可視性の恩恵を受けます。
The IETF has defined the Path Computation Element (PCE) [RFC4655] as a mechanism for achieving the computation of end-to-end TE paths that cross the visibility of more than one TED or that require CPU-intensive or coordinated computations. The IETF has also defined the ALTO server [RFC5693] as an entity that generates an abstracted network topology and provides it to network-aware applications.
IETFは、Path Computation Element（PCE）[RFC4655]を、複数のTEDの可視性を超えるエンドツーエンドのTEパスの計算を達成するためのメカニズム、またはCPU集約型または協調型計算を必要とするメカニズムとして定義しました。 IETFはまた、ALTOサーバー[RFC5693]を、抽象化されたネットワークトポロジを生成し、ネットワーク対応のアプリケーションに提供するエンティティとして定義しています。
Both a PCE and an ALTO server need to gather information about the topologies and capabilities of the network in order to be able to fulfill their function.
PCEとALTOサーバーの両方が機能を実行できるようにするには、ネットワークのトポロジーと機能に関する情報を収集する必要があります。
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol [RFC4271]. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual links. The mechanism described is subject to policy control.
このドキュメントでは、リンクステートとTEの情報をネットワークから収集し、BGPルーティングプロトコル[RFC4271]を使用して外部コンポーネントと共有できるメカニズムについて説明します。これは、新しいBGPネットワーク層到達可能性情報（NLRI）エンコード形式を使用して実現されます。このメカニズムは、物理リンクと仮想リンクに適用できます。説明されているメカニズムはポリシー制御の対象です。
A router maintains one or more databases for storing link-state information about nodes and links in any given area. Link attributes stored in these databases include: local/remote IP addresses, local/ remote interface identifiers, link metric and TE metric, link bandwidth, reservable bandwidth, per Class-of-Service (CoS) class reservation state, preemption, and Shared Risk Link Groups (SRLGs). The router's BGP process can retrieve topology from these LSDBs and distribute it to a consumer, either directly or via a peer BGP speaker (typically a dedicated Route Reflector), using the encoding specified in this document.
ルーターは、任意の領域のノードとリンクに関するリンク状態情報を格納するための1つ以上のデータベースを維持します。これらのデータベースに保存されているリンク属性には、ローカル/リモートIPアドレス、ローカル/リモートインターフェイス識別子、リンクメトリックとTEメトリック、リンク帯域幅、予約可能な帯域幅、サービスクラス（CoS）クラスごとの予約状態、プリエンプション、共有リスクがあります。リンクグループ（SRLG）。ルータのBGPプロセスは、これらのLSDBからトポロジを取得し、このドキュメントで指定されているエンコーディングを使用して、直接またはピアBGPスピーカー（通常は専用ルートリフレクタ）を介してコンシューマに配布できます。
The collection of link-state and TE information and its distribution to consumers is shown in the following figure.
次の図は、リンク状態とTEの情報の収集とその消費者への配布を示しています。
+-----------+
| Consumer |
+-----------+
^
|
+-----------+
| BGP | +-----------+
| Speaker | | Consumer |
+-----------+ +-----------+
^ ^ ^ ^
| | | |
+---------------+ | +-------------------+ |
| | | |
+-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker |
+-----------+ +-----------+ +-----------+
^ ^ ^
| | |
IGP IGP IGP
Figure 1: Collection of Link-State and TE Information
図1：リンクステートとTE情報の収集
A BGP speaker may apply configurable policy to the information that it distributes. Thus, it may distribute the real physical topology from the LSDB or the TED. Alternatively, it may create an abstracted topology, where virtual, aggregated nodes are connected by virtual paths. Aggregated nodes can be created, for example, out of multiple routers in a Point of Presence (POP). Abstracted topology can also be a mix of physical and virtual nodes and physical and virtual links. Furthermore, the BGP speaker can apply policy to determine when information is updated to the consumer so that there is a reduction of information flow from the network to the consumers. Mechanisms through which topologies can be aggregated or virtualized are outside the scope of this document
BGPスピーカーは、配信する情報に構成可能なポリシーを適用できます。したがって、実際の物理トポロジーをLSDBまたはTEDから配布できます。あるいは、仮想の集約ノードが仮想パスによって接続されている抽象化されたトポロジを作成することもできます。集約ノードは、たとえば、Point of Presence（POP）内の複数のルーターから作成できます。抽象化されたトポロジは、物理ノードと仮想ノード、および物理リンクと仮想リンクを組み合わせたものにすることもできます。さらに、BGPスピーカーはポリシーを適用して、情報がコンシューマーにいつ更新されるかを決定できるため、ネットワークからコンシューマーへの情報フローが減少します。トポロジを集約または仮想化できるメカニズムは、このドキュメントの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This section describes use cases from which the requirements can be derived.
このセクションでは、要件を導き出すことができるユースケースについて説明します。
As described in [RFC4655], a PCE can be used to compute MPLS-TE paths within a "domain" (such as an IGP area) or across multiple domains (such as a multi-area AS or multiple ASes).
[RFC4655]で説明されているように、PCEを使用して、「ドメイン」内（IGPエリアなど）または複数のドメイン間（マルチエリアASまたは複数のASなど）にわたるMPLS-TEパスを計算できます。
o Within a single area, the PCE offers enhanced computational power that may not be available on individual routers, sophisticated policy control and algorithms, and coordination of computation across the whole area.
o 単一のエリア内では、PCEは、個々のルーターでは利用できない可能性のある高度な計算能力、高度なポリシー制御とアルゴリズム、およびエリア全体にわたる計算の調整を提供します。
o If a router wants to compute a MPLS-TE path across IGP areas, then its own TED lacks visibility of the complete topology. That means that the router cannot determine the end-to-end path and cannot even select the right exit router (Area Border Router (ABR)) for an optimal path. This is an issue for large-scale networks that need to segment their core networks into distinct areas but still want to take advantage of MPLS-TE.
o ルータがIGPエリア全体のMPLS-TEパスを計算する場合、独自のTEDには完全なトポロジの可視性がありません。つまり、ルーターはエンドツーエンドのパスを判別できず、最適なパスとして適切な出口ルーター（Area Border Router（ABR））を選択することもできません。これは、コアネットワークを個別の領域にセグメント化する必要があるが、MPLS-TEを利用したい大規模ネットワークにとっては問題です。
Previous solutions used per-domain path computation [RFC5152]. The source router could only compute the path for the first area because the router only has full topological visibility for the first area along the path, but not for subsequent areas. Per-domain path computation uses a technique called "loose-hop-expansion" [RFC3209] and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) using the IGP-computed shortest path topology for the remainder of the path. This may lead to sub-optimal paths, makes alternate/back-up path computation hard, and might result in no TE path being found when one really does exist.
以前のソリューションは、ドメインごとのパス計算を使用していました[RFC5152]。ソースルーターは、最初のエリアのパスのみを計算できます。これは、ルーターがパスに沿った最初のエリアに対してのみ完全なトポロジーの可視性を持ち、後続のエリアに対してはそうでないためです。ドメインごとのパス計算では、「ルーズホップ拡張」[RFC3209]と呼ばれる手法を使用し、パスの残りの部分に対してIGP計算の最短パストポロジを使用して、出口ABRおよび他のABRまたはASボーダールータ（ASBR）を選択します。これにより、パスが最適化されず、代替/バックアップパスの計算が困難になり、実際に存在するTEパスが見つからない場合があります。
The PCE presents a computation server that may have visibility into more than one IGP area or AS, or may cooperate with other PCEs to perform distributed path computation. The PCE obviously needs access to the TED for the area(s) it serves, but [RFC4655] does not describe how this is achieved. Many implementations make the PCE a passive participant in the IGP so that it can learn the latest state of the network, but this may be sub-optimal when the network is subject to a high degree of churn or when the PCE is responsible for multiple areas.
PCEは、複数のIGPエリアまたはASへの可視性があるか、他のPCEと連携して分散パス計算を実行できる計算サーバーを提供します。 PCEは、それがサービスを提供するエリアのTEDへのアクセスを明らかに必要としますが、[RFC4655]は、これがどのように達成されるかについては述べていません。多くの実装では、PCEをIGPのパッシブ参加者にして、ネットワークの最新の状態を学習できるようにしますが、ネットワークが高度なチャーンの影響を受けている場合や、PCEが複数の領域を担当している場合、これは最適とは言えません。
The following figure shows how a PCE can get its TED information using the mechanism described in this document.
次の図は、PCEがこのドキュメントで説明されているメカニズムを使用してTED情報を取得する方法を示しています。
+----------+ +---------+
| ----- | | BGP |
| | TED |<-+-------------------------->| Speaker |
| ----- | TED synchronization | |
| | | mechanism: +---------+
| | | BGP with Link-State NLRI
| v |
| ----- |
| | PCE | |
| ----- |
+----------+
^
| Request/
| Response
v
Service +----------+ Signaling +----------+
Request | Head-End | Protocol | Adjacent |
-------->| Node |<------------>| Node |
+----------+ +----------+
Figure 2: External PCE Node Using a TED Synchronization Mechanism
図2：TED同期メカニズムを使用する外部PCEノード
The mechanism in this document allows the necessary TED information to be collected from the IGP within the network, filtered according to configurable policy, and distributed to the PCE as necessary.
このドキュメントのメカニズムにより、必要なTED情報をネットワーク内のIGPから収集し、構成可能なポリシーに従ってフィルタリングし、必要に応じてPCEに配布できます。
An ALTO server [RFC5693] is an entity that generates an abstracted network topology and provides it to network-aware applications over a web-service-based API. Example applications are peer-to-peer (P2P) clients or trackers, or Content Distribution Networks (CDNs). The abstracted network topology comes in the form of two maps: a Network Map that specifies allocation of prefixes to Partition Identifiers (PIDs), and a Cost Map that specifies the cost between PIDs listed in the Network Map. For more details, see [RFC7285].
ALTOサーバー[RFC5693]は、抽象化されたネットワークトポロジを生成し、それをWebサービスベースのAPIを介してネットワーク対応アプリケーションに提供するエンティティです。アプリケーションの例は、ピアツーピア（P2P）クライアントまたはトラッカー、またはコンテンツ配信ネットワーク（CDN）です。抽象化されたネットワークトポロジは、パーティション識別子（PID）へのプレフィックスの割り当てを指定するネットワークマップと、ネットワークマップにリストされているPID間のコストを指定するコストマップの2つのマップの形で提供されます。詳細については、[RFC7285]を参照してください。
ALTO abstract network topologies can be auto-generated from the physical topology of the underlying network. The generation would typically be based on policies and rules set by the operator. Both prefix and TE data are required: prefix data is required to generate ALTO Network Maps, and TE (topology) data is required to generate ALTO Cost Maps. Prefix data is carried and originated in BGP, and TE data is originated and carried in an IGP. The mechanism defined in this document provides a single interface through which an ALTO server can retrieve all the necessary prefix and network topology data from the underlying network. Note that an ALTO server can use other mechanisms to get network data, for example, peering with multiple IGP and BGP speakers.
ALTO抽象ネットワークトポロジは、基盤となるネットワークの物理トポロジから自動生成できます。生成は通常、オペレーターが設定したポリシーとルールに基づいて行われます。プレフィックスとTEの両方のデータが必要です。ALTOネットワークマップを生成するにはプレフィックスデータが必要であり、ALTOコストマップを生成するにはTE（トポロジ）データが必要です。プレフィックスデータはBGPで伝送および発信され、TEデータはIGPで発信および伝送されます。このドキュメントで定義されているメカニズムは、ALTOサーバーが基盤となるネットワークから必要なすべてのプレフィックスとネットワークトポロジデータを取得できる単一のインターフェースを提供します。 ALTOサーバーは他のメカニズムを使用してネットワークデータを取得できることに注意してください。たとえば、複数のIGPおよびBGPスピーカーとのピアリングなどです。
The following figure shows how an ALTO server can get network topology information from the underlying network using the mechanism described in this document.
次の図は、ALTOサーバーが、このドキュメントで説明されているメカニズムを使用して、基盤となるネットワークからネットワークトポロジ情報を取得する方法を示しています。
+--------+
| Client |<--+
+--------+ |
| ALTO +--------+ BGP with +---------+
+--------+ | Protocol | ALTO | Link-State NLRI | BGP |
| Client |<--+------------| Server |<----------------| Speaker |
+--------+ | | | | |
| +--------+ +---------+
+--------+ |
| Client |<--+
+--------+
Figure 3: ALTO Server Using Network Topology Information
図3：ネットワークトポロジ情報を使用したALTOサーバー
This specification contains two parts: definition of a new BGP NLRI that describes links, nodes, and prefixes comprising IGP link-state information and definition of a new BGP path attribute (BGP-LS attribute) that carries link, node, and prefix properties and attributes, such as the link and prefix metric or auxiliary Router-IDs of nodes, etc.
この仕様には2つの部分が含まれます。IGPリンク状態情報を構成するリンク、ノード、およびプレフィックスを記述する新しいBGP NLRIの定義と、リンク、ノード、およびプレフィックスプロパティを運ぶ新しいBGPパス属性（BGP-LS属性）の定義、およびノードのリンクおよびプレフィックスメトリックまたは補助ルーターIDなどの属性
It is desirable to keep the dependencies on the protocol source of this attribute to a minimum and represent any content in an IGP-neutral way, such that applications that want to learn about a link-state topology do not need to know about any OSPF or IS-IS protocol specifics.
この属性のプロトコルソースへの依存関係を最小限に抑え、コンテンツをIGPに中立な方法で表すことが望ましいため、リンク状態トポロジについて学習したいアプリケーションは、OSPFまたはIS-ISプロトコルの詳細。
Information in the new Link-State NLRIs and attributes is encoded in Type/Length/Value triplets. The TLV format is shown in Figure 4.
新しいリンクステートNLRIと属性の情報は、タイプ/長さ/値のトリプレットでエンコードされます。 TLVフォーマットを図4に示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TLV Format
図4：TLVフォーマット
The Length field defines the length of the value portion in octets (thus, a TLV with no value portion would have a length of zero). The TLV is not padded to 4-octet alignment. Unrecognized types MUST be preserved and propagated. In order to compare NLRIs with unknown TLVs, all TLVs MUST be ordered in ascending order by TLV Type. If there are more TLVs of the same type, then the TLVs MUST be ordered in ascending order of the TLV value within the TLVs with the same type by treating the entire Value field as an opaque hexadecimal string and comparing leftmost octets first, regardless of the length of the string. All TLVs that are not specified as mandatory are considered optional.
長さフィールドは、値の部分の長さをオクテットで定義します（したがって、値の部分がないTLVの長さはゼロになります）。 TLVは4オクテットアライメントにパディングされません。認識されないタイプは保存して伝播する必要があります。 NLRIと未知のTLVを比較するには、すべてのTLVをTLVタイプで昇順に並べる必要があります。同じタイプのTLVがさらにある場合、Valueフィールド全体を不透明な16進文字列として扱い、左端のオクテットを最初に比較することにより、TLVは同じタイプのTLV内のTLV値の昇順で並べる必要があります。文字列の長さ。必須として指定されていないすべてのTLVはオプションと見なされます。
The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers for carrying opaque information. Each Link-State NLRI describes either a node, a link, or a prefix.
MP_REACH_NLRIおよびMP_UNREACH_NLRI属性は、不透明な情報を運ぶためのBGPのコンテナーです。各リンクステートNLRIは、ノード、リンク、またはプレフィックスのいずれかを記述します。
All non-VPN link, node, and prefix information SHALL be encoded using AFI 16388 / SAFI 71. VPN link, node, and prefix information SHALL be encoded using AFI 16388 / SAFI 72.
すべての非VPNリンク、ノード、およびプレフィックス情報は、AFI 16388 / SAFI 71を使用してエンコードする必要があります。VPNリンク、ノード、およびプレフィックス情報は、AFI 16388 / SAFI 72を使用してエンコードする必要があります。
In order for two BGP speakers to exchange Link-State NLRI, they MUST use BGP Capabilities Advertisement to ensure that they are both capable of properly processing such NLRI. This is done as specified in [RFC4760], by using capability code 1 (multi-protocol BGP), with AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for BGP-LS-VPN.
2つのBGPスピーカーがリンクステートNLRIを交換するには、BGP機能アドバタイズを使用して、両方がそのようなNLRIを適切に処理できることを確認する必要があります。これは、[RFC4760]で指定されているように、機能コード1（マルチプロトコルBGP）を使用し、BGP-LSの場合はAFI 16388 / SAFI 71、BGP-LS-VPNの場合はAFI 16388 / SAFI 72を使用します。
The format of the Link-State NLRI is shown in the following figures.
リンクステートNLRIのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format
図5：リンクステートAFI 16388 / SAFI 71 NLRIフォーマット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Route Distinguisher +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format
図6：リンクステートVPN AFI 16388 / SAFI 72 NLRIフォーマット
The Total NLRI Length field contains the cumulative length, in octets, of the rest of the NLRI, not including the NLRI Type field or itself. For VPN applications, it also includes the length of the Route Distinguisher.
Total NLRI Lengthフィールドには、NLRI Typeフィールドまたはそれ自体を含まない、残りのNLRIのオクテット単位の累積長が含まれます。 VPNアプリケーションの場合、Route Distinguisherの長さも含まれます。
+------+---------------------------+
| Type | NLRI Type |
+------+---------------------------+
| 1 | Node NLRI |
| 2 | Link NLRI |
| 3 | IPv4 Topology Prefix NLRI |
| 4 | IPv6 Topology Prefix NLRI |
+------+---------------------------+
Table 1: NLRI Types
表1：NLRIタイプ
Route Distinguishers are defined and discussed in [RFC4364].
ルート識別子は、[RFC4364]で定義および説明されています。
The Node NLRI (NLRI Type = 1) is shown in the following figure.
ノードNLRI（NLRIタイプ= 1）を次の図に示します。
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: The Node NLRI Format
図7：ノードNLRI形式
The Link NLRI (NLRI Type = 2) is shown in the following figure.
リンクNLRI（NLRIタイプ= 2）を次の図に示します。
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: The Link NLRI Format
図8：リンクNLRI形式
The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the same format, as shown in the following figure.
次の図に示すように、IPv4およびIPv6プレフィックスNLRI（NLRIタイプ= 3およびタイプ= 4）は同じ形式を使用します。
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The IPv4/IPv6 Topology Prefix NLRI Format
図9：IPv4 / IPv6トポロジプレフィックスNLRI形式
The Protocol-ID field can contain one of the following values:
Protocol-IDフィールドには、次のいずれかの値を含めることができます。
+-------------+----------------------------------+
| Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+
| 1 | IS-IS Level 1 |
| 2 | IS-IS Level 2 |
| 3 | OSPFv2 |
| 4 | Direct |
| 5 | Static configuration |
| 6 | OSPFv3 |
+-------------+----------------------------------+
Table 2: Protocol Identifiers
表2：プロトコル識別子
The 'Direct' and 'Static configuration' protocol types SHOULD be used when BGP-LS is sourcing local information. For all information derived from other protocols, the corresponding Protocol-ID MUST be used. If BGP-LS has direct access to interface information and wants to advertise a local link, then the Protocol-ID 'Direct' SHOULD be used. For modeling virtual links, such as described in Section 4, the Protocol-ID 'Static configuration' SHOULD be used.
「直接」および「静的構成」プロトコルタイプは、BGP-LSがローカル情報を取得しているときに使用する必要があります（SHOULD）。他のプロトコルから派生したすべての情報については、対応するプロトコルIDを使用する必要があります。 BGP-LSがインターフェイス情報に直接アクセスでき、ローカルリンクをアドバタイズする場合は、プロトコルID「ダイレクト」を使用する必要があります（SHOULD）。セクション4で説明されているような仮想リンクのモデリングには、プロトコルID「静的構成」を使用する必要があります。
Both OSPF and IS-IS MAY run multiple routing protocol instances over the same link. See [RFC6822] and [RFC6549]. These instances define independent "routing universes". The 64-bit Identifier field is used to identify the routing universe where the NLRI belongs. The NLRIs representing link-state objects (nodes, links, or prefixes) from the same routing universe MUST have the same 'Identifier' value. NLRIs with different 'Identifier' values MUST be considered to be from different routing universes. Table 3 lists the 'Identifier' values that are defined as well-known in this document.
OSPFとIS-ISの両方が、同じリンク上で複数のルーティングプロトコルインスタンスを実行する場合があります。 [RFC6822]と[RFC6549]を参照してください。これらのインスタンスは、独立した「ルーティングユニバース」を定義します。 64ビットの識別子フィールドは、NLRIが属するルーティングユニバースを識別するために使用されます。同じルーティングユニバースからのリンク状態オブジェクト（ノード、リンク、またはプレフィックス）を表すNLRIは、同じ '識別子'値を持つ必要があります。 「識別子」の値が異なるNLRIは、異なるルーティングユニバースからのものであると見なす必要があります。表3は、このドキュメントでよく知られているように定義されている「識別子」の値を示しています。
+------------+----------------------------------+
| Identifier | Routing Universe |
+------------+----------------------------------+
| 0 | Default Layer 3 Routing topology |
+------------+----------------------------------+
Table 3: Well-Known Instance Identifiers
表3：既知のインスタンス識別子
If a given protocol does not support multiple routing universes, then it SHOULD set the Identifier field according to Table 3. However, an implementation MAY make the 'Identifier' configurable for a given protocol.
特定のプロトコルが複数のルーティングユニバースをサポートしていない場合は、表3に従って識別子フィールドを設定する必要があります（SHOULD）。ただし、実装は、特定のプロトコルに対して「識別子」を構成可能にする場合があります。
Each Node Descriptor and Link Descriptor consists of one or more TLVs, as described in the following sections.
次のセクションで説明するように、各ノード記述子とリンク記述子は1つ以上のTLVで構成されます。
Each link is anchored by a pair of Router-IDs that are used by the underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a 32-bit Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more additional auxiliary Router-IDs, mainly for Traffic Engineering purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE Router-IDs [RFC5305] [RFC6119]. These auxiliary Router-IDs MUST be included in the link attribute described in Section 3.3.2.
各リンクは、基礎となるIGPで使用されるルーターIDのペア、つまりIS-ISの48ビットISOシステムIDと、OSPFv2およびOSPFv3の32ビットルーターIDによってアンカーされています。 IGPは、主にトラフィックエンジニアリングの目的で、1つ以上の追加の補助ルーターIDを使用できます。たとえば、IS-ISには1つ以上のIPv4およびIPv6 TEルーターID [RFC5305] [RFC6119]がある場合があります。これらの補助ルーターIDは、セクション3.3.2で説明されているリンク属性に含まれている必要があります。
It is desirable that the Router-ID assignments inside the Node Descriptor are globally unique. However, there may be Router-ID spaces (e.g., ISO) where no global registry exists, or worse, Router-IDs have been allocated following the private-IP allocation described in RFC 1918 [RFC1918]. BGP-LS uses the Autonomous System (AS) Number and BGP-LS Identifier (see Section 3.2.1.4) to disambiguate the Router-IDs, as described in Section 3.2.1.1.
ノード記述子内のルーターID割り当ては、グローバルに一意であることが望ましいです。ただし、グローバルレジストリが存在しないルーターIDスペース（ISOなど）がある可能性があります。さらに悪いことに、RFC 1918 [RFC1918]で説明されているプライベートIP割り当てに従ってルーターIDが割り当てられています。 BGP-LSは、自律システム（AS）番号とBGP-LS識別子（セクション3.2.1.4を参照）を使用して、セクション3.2.1.1で説明されているようにルーターIDを明確にします。
One problem that needs to be addressed is the ability to identify an IGP node globally (by "globally", we mean within the BGP-LS database collected by all BGP-LS speakers that talk to each other). This can be expressed through the following two requirements:
対処する必要がある1つの問題は、IGPノードをグローバルに識別する機能です（「グローバルに」とは、互いに通信するすべてのBGP-LSスピーカーによって収集されるBGP-LSデータベース内を意味します）。これは、次の2つの要件によって表すことができます。
(A) The same node MUST NOT be represented by two keys (otherwise, one node will look like two nodes).
（A）同じノードを2つのキーで表すことはできません（そうでない場合、1つのノードは2つのノードのように見えます）。
(B) Two different nodes MUST NOT be represented by the same key (otherwise, two nodes will look like one node).
（B）2つの異なるノードを同じキーで表すことはできません（そうでない場合、2つのノードは1つのノードのように見えます）。
We define an "IGP domain" to be the set of nodes (hence, by extension links and prefixes) within which each node has a unique IGP representation by using the combination of Area-ID, Router-ID, Protocol-ID, Multi-Topology ID, and Instance-ID. The problem is that BGP may receive node/link/prefix information from multiple independent "IGP domains", and we need to distinguish between them. Moreover, we can't assume there is always one and only one IGP domain per AS. During IGP transitions, it may happen that two redundant IGPs are in place.
Area-ID、Router-ID、Protocol-ID、Multi-の組み合わせを使用して、各ノードが一意のIGP表現を持つノードのセット（つまり、拡張リンクとプレフィックス）として「IGPドメイン」を定義しますトポロジID、およびインスタンスID。問題は、BGPが複数の独立した「IGPドメイン」からノード/リンク/プレフィックス情報を受信する可能性があり、それらを区別する必要があることです。さらに、ASごとにIGPドメインが常に1つしかないとは限りません。 IGPの移行中に、2つの冗長IGPが配置されることがあります。
In Section 3.2.1.4, a set of sub-TLVs is described, which allows specification of a flexible key for any given node/link information such that global uniqueness of the NLRI is ensured.
セクション3.2.1.4では、一連のサブTLVが説明されています。これにより、NLRIのグローバルな一意性が保証されるように、任意のノード/リンク情報に柔軟なキーを指定できます。
The Local Node Descriptors TLV contains Node Descriptors for the node anchoring the local end of the link. This is a mandatory TLV in all three types of NLRIs (node, link, and prefix). The length of this TLV is variable. The value contains one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4.
ローカルノード記述子TLVには、リンクのローカルエンドを固定するノードのノード記述子が含まれています。これは、3種類すべてのNLRI（ノード、リンク、およびプレフィックス）で必須のTLVです。このTLVの長さは可変です。値には、セクション3.2.1.4で定義された1つ以上のノード記述子サブ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Local Node Descriptors TLV Format
図10：ローカルノード記述子TLV形式
The Remote Node Descriptors TLV contains Node Descriptors for the node anchoring the remote end of the link. This is a mandatory TLV for Link NLRIs. The length of this TLV is variable. The value contains one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4.
リモートノード記述子TLVには、リンクのリモートエンドを固定するノードのノード記述子が含まれています。これはリンクNLRIの必須TLVです。このTLVの長さは可変です。値には、セクション3.2.1.4で定義された1つ以上のノード記述子サブ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Remote Node Descriptors TLV Format
図11：リモートノード記述子TLV形式
The Node Descriptor Sub-TLV type code points and lengths are listed in the following table:
Node Descriptor Sub-TLVタイプのコードポイントと長さを次の表に示します。
+--------------------+-------------------+----------+
| Sub-TLV Code Point | Description | Length |
+--------------------+-------------------+----------+
| 512 | Autonomous System | 4 |
| 513 | BGP-LS Identifier | 4 |
| 514 | OSPF Area-ID | 4 |
| 515 | IGP Router-ID | Variable |
+--------------------+-------------------+----------+
Table 4: Node Descriptor Sub-TLVs
表4：ノード記述子サブTLV
The sub-TLV values in Node Descriptor TLVs are defined as follows:
ノード記述子TLVのサブTLV値は、次のように定義されます。
Autonomous System: Opaque value (32-bit AS Number)
自律システム：不透明な値（32ビットAS番号）
BGP-LS Identifier: Opaque value (32-bit ID). In conjunction with Autonomous System Number (ASN), uniquely identifies the BGP-LS domain. The combination of ASN and BGP-LS ID MUST be globally unique. All BGP-LS speakers within an IGP flooding-set (set of IGP nodes within which an LSP/LSA is flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP domain consists of multiple flooding-sets, then all BGP-LS speakers within the IGP domain SHOULD use the same ASN, BGP-LS ID tuple.
BGP-LS識別子：不透明な値（32ビットID）。自律システム番号（ASN）と組み合わせて、BGP-LSドメインを一意に識別します。 ASNとBGP-LS IDの組み合わせは、グローバルに一意である必要があります。 IGPフラッディングセット（LSP / LSAがフラッディングされるIGPノードのセット）内のすべてのBGP-LSスピーカーは、同じASN、BGP-LS IDタプルを使用する必要があります。 IGPドメインが複数のフラッディングセットで構成されている場合、IGPドメイン内のすべてのBGP-LSスピーカーは同じASN、BGP-LS IDタプルを使用する必要があります（SHOULD）。
Area-ID: Used to identify the 32-bit area to which the NLRI belongs. The Area Identifier allows different NLRIs of the same router to be discriminated.
Area-ID：NLRIが属する32ビット領域を識別するために使用されます。エリア識別子を使用すると、同じルーターの異なるNLRIを区別できます。
IGP Router-ID: Opaque value. This is a mandatory TLV. For an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISO system-ID). For an IS-IS pseudonode corresponding to a LAN, this contains the 6-octet ISO Node-ID of the Designated Intermediate System (DIS) followed by a 1-octet, nonzero PSN identifier (7 octets in total). For an OSPFv2 or OSPFv3 non-pseudonode, this contains the 4-octet Router-ID. For an OSPFv2 pseudonode representing a LAN, this contains the 4-octet Router-ID of the Designated Router (DR) followed by the 4-octet IPv4 address of the DR's interface to the LAN (8 octets in total). Similarly, for an OSPFv3 pseudonode, this contains the 4-octet Router-ID of the DR followed by the 4-octet interface identifier of the DR's interface to the LAN (8 octets in total). The TLV size in combination with the protocol identifier enables the decoder to determine the type of the node.
IGPルーターID：不透明な値。これは必須のTLVです。 IS-IS非疑似ノードの場合、これには6オクテットのISOノードID（ISOシステムID）が含まれます。 LANに対応するIS-IS疑似ノードの場合、これには指定中間システム（DIS）の6オクテットISOノードIDが含まれ、その後に1オクテット、ゼロ以外のPSN識別子（合計7オクテット）が続きます。 OSPFv2またはOSPFv3非疑似ノードの場合、これには4オクテットのルーターIDが含まれます。 LANを表すOSPFv2疑似ノードの場合、これには代表ルーター（DR）の4オクテットのルーターIDが含まれ、その後にLANへのDRインターフェースの4オクテットIPv4アドレス（合計8オクテット）が続きます。同様に、OSPFv3疑似ノードの場合、これには、DRの4オクテットのルーターIDと、それに続く、LANへのDRインターフェースの4オクテットのインターフェースID（合計8オクテット）が含まれます。 TLVサイズとプロトコル識別子を組み合わせることにより、デコーダーはノードのタイプを判別できます。
There can be at most one instance of each sub-TLV type present in any Node Descriptor. The sub-TLVs within a Node Descriptor MUST be arranged in ascending order by sub-TLV type. This needs to be done in order to compare NLRIs, even when an implementation encounters an unknown sub-TLV. Using stable sorting, an implementation can do binary comparison of NLRIs and hence allow incremental deployment of new key sub-TLVs.
任意のノード記述子に存在する各サブTLVタイプのインスタンスは最大1つです。ノード記述子内のサブTLVは、サブTLVタイプ別に昇順で配置する必要があります。これは、実装が不明なサブTLVに遭遇した場合でも、NLRIを比較するために実行する必要があります。安定したソートを使用すると、実装はNLRIのバイナリ比較を実行できるため、新しい主要なサブTLVを段階的に展開できます。
The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF Multi-Topology IDs for a link, node, or prefix.
マルチトポロジID（MT-ID）TLVは、リンク、ノード、またはプレフィックスの1つ以上のIS-ISまたはOSPFマルチトポロジIDを伝送します。
Semantics of the IS-IS MT-ID are defined in Section 7.2 of RFC 5120 [RFC5120]. Semantics of the OSPF MT-ID are defined in Section 3.7 of RFC 4915 [RFC4915]. If the value in the MT-ID TLV is derived from OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved and SHOULD be set to 0 when originated and ignored on receipt.
IS-IS MT-IDのセマンティクスは、RFC 5120 [RFC5120]のセクション7.2で定義されています。 OSPF MT-IDのセマンティクスは、RFC 4915 [RFC4915]のセクション3.7で定義されています。 MT-ID TLVの値がOSPFから派生している場合、上位9ビットは0に設定する必要があります。ビットRは予約されており、発生時に0に設定して、受信時に無視する必要があります。
The format of the MT-ID TLV is shown in the following figure.
MT-ID 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=2*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| Multi-Topology ID 1 | .... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// .... |R R R R| Multi-Topology ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Multi-Topology ID TLV Format
図12：マルチトポロジID TLV形式
where Type is 263, Length is 2*n, and n is the number of MT-IDs carried in the TLV.
Typeは263、Lengthは2 * n、nはTLVで伝送されるMT-IDの数です。
The MT-ID TLV MAY be present in a Link Descriptor, a Prefix Descriptor, or the BGP-LS attribute of a Node NLRI. In a Link or Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of the topology where the link or the prefix is reachable is allowed. In case one wants to advertise multiple topologies for a given Link Descriptor or Prefix Descriptor, multiple NLRIs need to be generated where each NLRI contains an unique MT-ID. In the BGP-LS attribute of a Node NLRI, one MT-ID TLV containing the array of MT-IDs of all topologies where the node is reachable is allowed.
MT-ID TLVは、リンク記述子、プレフィックス記述子、またはノードNLRIのBGP-LS属性に存在する場合があります。リンクまたはプレフィックス記述子では、リンクまたはプレフィックスが到達可能なトポロジのMT-IDを含む単一のMT-ID TLVのみが許可されます。特定のリンク記述子またはプレフィックス記述子の複数のトポロジをアドバタイズする場合は、各NLRIに一意のMT-IDが含まれる複数のNLRIを生成する必要があります。ノードNLRIのBGP-LS属性では、ノードが到達可能なすべてのトポロジのMT-IDの配列を含む1つのMT-ID TLVが許可されます。
The Link Descriptor field is a set of Type/Length/Value (TLV) triplets. The format of each TLV is shown in Section 3.1. The Link Descriptor TLVs uniquely identify a link among multiple parallel links between a pair of anchor routers. A link described by the Link Descriptor TLVs actually is a "half-link", a unidirectional representation of a logical link. In order to fully describe a single logical link, two originating routers advertise a half-link each, i.e., two Link NLRIs are advertised for a given point-to-point link.
リンク記述子フィールドは、タイプ/長さ/値（TLV）トリプレットのセットです。各TLVのフォーマットはセクション3.1に示されています。リンク記述子TLVは、アンカールーターのペア間の複数の並列リンクの中からリンクを一意に識別します。リンク記述子TLVによって記述されるリンクは、実際には「ハーフリンク」であり、論理リンクの一方向表現です。単一の論理リンクを完全に説明するために、2つの発信元ルーターがそれぞれハーフリンクをアドバタイズします。つまり、特定のポイントツーポイントリンクに対して2つのリンクNLRIがアドバタイズされます。
The format and semantics of the Value fields in most Link Descriptor TLVs correspond to the format and semantics of Value fields in IS-IS Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307], and [RFC6119]. Although the encodings for Link Descriptor TLVs were originally defined for IS-IS, the TLVs can carry data sourced by either IS-IS or OSPF.
ほとんどのリンク記述子TLVの値フィールドのフォーマットとセマンティクスは、[RFC5305]、[RFC5307]、および[RFC6119]で定義されているIS-IS拡張IS到達可能性サブTLVの値フィールドのフォーマットとセマンティクスに対応しています。リンク記述子TLVのエンコーディングは元々IS-IS用に定義されていましたが、TLVはIS-ISまたはOSPFのいずれかから供給されたデータを伝送できます。
The following TLVs are valid as Link Descriptors in the Link NLRI:
次のTLVは、リンクNLRIのリンク記述子として有効です。
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 |
| | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 |
| | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 |
| | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 |
| | address | | |
| 263 | Multi-Topology | --- | Section 3.2.1.5 |
| | Identifier | | |
+-----------+---------------------+--------------+------------------+
Table 5: Link Descriptor TLVs
表5：リンク記述子TLV
The information about a link present in the LSA/LSP originated by the local node of the link determines the set of TLVs in the Link Descriptor of the link.
リンクのローカルノードによって発信されたLSA / LSPに存在するリンクに関する情報は、リンクのリンク記述子内のTLVのセットを決定します。
If interface and neighbor addresses, either IPv4 or IPv6, are present, then the IP address TLVs are included in the Link Descriptor but not the link local/remote Identifier TLV. The link local/remote identifiers MAY be included in the link attribute.
IPv4またはIPv6のいずれかのインターフェイスおよびネイバーアドレスが存在する場合、IPアドレスTLVはリンク記述子に含まれますが、リンクローカル/リモート識別子TLVには含まれません。リンクローカル/リモート識別子は、リンク属性に含まれる場合があります。
If interface and neighbor addresses are not present and the link local/remote identifiers are present, then the link local/remote Identifier TLV is included in the Link Descriptor.
インターフェイスとネイバーアドレスが存在せず、リンクローカル/リモート識別子が存在する場合、リンクローカル/リモート識別子TLVがリンク記述子に含まれます。
The Multi-Topology Identifier TLV is included in Link Descriptor if that information is present.
マルチトポロジ識別子TLVは、その情報が存在する場合、リンク記述子に含まれています。
The Prefix Descriptor field is a set of Type/Length/Value (TLV) triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6 prefix originated by a node. The following TLVs are valid as Prefix Descriptors in the IPv4/IPv6 Prefix NLRI:
Prefix Descriptorフィールドは、タイプ/長さ/値（TLV）トリプレットのセットです。プレフィックス記述子TLVは、ノードから発信されたIPv4またはIPv6プレフィックスを一意に識別します。次のTLVは、IPv4 / IPv6プレフィックスNLRIのプレフィックス記述子として有効です。
+-------------+---------------------+----------+--------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+---------------------+----------+--------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 264 | OSPF Route Type | 1 | Section 3.2.3.1 |
| 265 | IP Reachability | variable | Section 3.2.3.2 |
| | Information | | |
+-------------+---------------------+----------+--------------------+
Table 6: Prefix Descriptor TLVs
表6：プレフィックス記述子TLV
The OSPF Route Type TLV is an optional TLV that MAY be present in Prefix NLRIs. It is used to identify the OSPF route type of the prefix. It is used when an OSPF prefix is advertised in the OSPF domain with multiple route types. The Route Type TLV allows the discrimination of these advertisements. The format of the OSPF Route Type TLV is shown in the following figure.
OSPFルートタイプTLVは、プレフィックスNLRIに存在してもよいオプションのTLVです。プレフィックスのOSPFルートタイプを識別するために使用されます。 OSPFプレフィックスが複数のルートタイプを持つOSPFドメインでアドバタイズされる場合に使用されます。ルートタイプTLVでは、これらのアドバタイズメントを区別できます。 OSPFルートタイプ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type |
+-+-+-+-+-+-+-+-+
Figure 13: OSPF Route Type TLV Format
図13：OSPFルートタイプTLV形式
where the Type and Length fields of the TLV are defined in Table 6. The OSPF Route Type field values are defined in the OSPF protocol and can be one of the following:
TLVのTypeフィールドとLengthフィールドは、表6で定義されています。OSPFRoute Typeフィールドの値は、OSPFプロトコルで定義され、次のいずれかになります。
o Intra-Area (0x1)
o エリア内（0x1）
o Inter-Area (0x2)
o エリア間（0x2）
o External 1 (0x3) o External 2 (0x4)
o外部1（0x3）o外部2（0x4）
o NSSA 1 (0x5)
o 1テキスト（0ダーティ）
o NSSA 2 (0x6)
o テキストA（0 cm）
The IP Reachability Information TLV is a mandatory TLV that contains one IP address prefix (IPv4 or IPv6) originally advertised in the IGP topology. Its purpose is to glue a particular BGP service NLRI by virtue of its BGP next hop to a given node in the LSDB. A router SHOULD advertise an IP Prefix NLRI for each of its BGP next hops. The format of the IP Reachability Information TLV is shown in the following figure:
IP到達可能性情報TLVは、IGPトポロジで最初にアドバタイズされた1つのIPアドレスプレフィックス（IPv4またはIPv6）を含む必須TLVです。その目的は、LSDB内の特定のノードへのBGPネクストホップにより、特定のBGPサービスNLRIを接着することです。ルーターは、BGPネクストホップごとにIPプレフィックスNLRIを通知する必要があります（SHOULD）。 IP到達可能性情報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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: IP Reachability Information TLV Format
図14：IP到達可能性情報のTLV形式
The Type and Length fields of the TLV are defined in Table 6. The following two fields determine the reachability information of the address family. The Prefix Length field contains the length of the prefix in bits. The IP Prefix field contains the most significant octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 24, 4 octets for prefix length 25 up to 32, etc.
TLVのTypeフィールドとLengthフィールドは、表6で定義されています。次の2つのフィールドは、アドレスファミリの到達可能性情報を決定します。プレフィックス長フィールドには、プレフィックスの長さがビット単位で含まれています。 IPプレフィックスフィールドには、プレフィックスの最も重要なオクテットが含まれます。つまり、プレフィックス長1〜8の場合は1オクテット、プレフィックス長9〜16の場合は2オクテット、プレフィックス長17〜24の場合は3オクテット、プレフィックス長25の場合は4オクテット最大32など
The BGP-LS attribute is an optional, non-transitive BGP attribute that is used to carry link, node, and prefix parameters and attributes. It is defined as a set of Type/Length/Value (TLV) triplets, described in the following section. This attribute SHOULD only be included with Link-State NLRIs. This attribute MUST be ignored for all other address families.
BGP-LS属性は、オプションの非推移的BGP属性であり、リンク、ノード、およびプレフィックスのパラメーターと属性を運ぶために使用されます。これは、次のセクションで説明するタイプ/長さ/値（TLV）トリプレットのセットとして定義されます。この属性は、リンクステートNLRIにのみ含める必要があります（SHOULD）。他のすべてのアドレスファミリでは、この属性を無視する必要があります。
Node attribute TLVs are the TLVs that may be encoded in the BGP-LS attribute with a Node NLRI. The following Node Attribute TLVs are defined:
ノード属性TLVは、ノードNLRIを使用してBGP-LS属性にエンコードできるTLVです。次のノード属性TLVが定義されています。
+-------------+----------------------+----------+-------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+----------------------+----------+-------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 1024 | Node Flag Bits | 1 | Section 3.3.1.1 |
| 1025 | Opaque Node | variable | Section 3.3.1.5 |
| | Attribute | | |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | |
| 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 |
| | Local Node | | |
+-------------+----------------------+----------+-------------------+
Table 7: Node Attribute TLVs
表7：ノード属性TLV
The Node Flag Bits TLV carries a bit mask describing node attributes. The value is a variable-length bit array of flags, where each bit represents a node capability.
ノードフラグビット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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|E|B|R|V| Rsvd|
+-+-+-+-+-+-+-+-+-+
Figure 15: Node Flag Bits TLV Format
図15：ノードフラグビットTLV形式
The bits are defined as follows:
ビットは次のように定義されています。
+-----------------+-------------------------+------------+
| Bit | Description | Reference |
+-----------------+-------------------------+------------+
| 'O' | Overload Bit | [ISO10589] |
| 'T' | Attached Bit | [ISO10589] |
| 'E' | External Bit | [RFC2328] |
| 'B' | ABR Bit | [RFC2328] |
| 'R' | Router Bit | [RFC5340] |
| 'V' | V6 Bit | [RFC5340] |
| Reserved (Rsvd) | Reserved for future use | |
+-----------------+-------------------------+------------+
Table 8: Node Flag Bits Definitions
表8：ノードフラグビットの定義
An IS-IS node can be part of one or more IS-IS areas. Each of these area addresses is carried in the IS-IS Area Identifier TLV. If multiple area addresses are present, multiple TLVs are used to encode them. The IS-IS Area Identifier TLV may be present in the BGP-LS attribute only when advertised in the Link-State Node NLRI.
IS-ISノードは、1つ以上のIS-ISエリアの一部にすることができます。これらの各エリアアドレスは、IS-ISエリア識別子TLVで伝送されます。複数のエリアアドレスが存在する場合、それらをエンコードするために複数のTLVが使用されます。 IS-ISエリア識別子TLVは、リンクステートノードNLRIでアドバタイズされた場合にのみ、BGP-LS属性に存在する可能性があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Area Identifier (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: IS-IS Area Identifier TLV Format
図16：IS-ISエリア識別子TLV形式
The Node Name TLV is optional. Its structure and encoding has been borrowed from [RFC5301]. The Value field identifies the symbolic name of the router node. This symbolic name can be the Fully Qualified Domain Name (FQDN) for the router, it can be a subset of the FQDN (e.g., a hostname), or it can be any string operators want to use for the router. The use of FQDN or a subset of it is strongly RECOMMENDED. The maximum length of the Node Name TLV is 255 octets.
ノード名TLVはオプションです。その構造とエンコーディングは[RFC5301]から借用されました。 「値」フィールドは、ルーター・ノードの記号名を識別します。このシンボリック名は、ルーターの完全修飾ドメイン名（FQDN）、FQDNのサブセット（ホスト名など）、またはルーターに使用する任意の文字列演算子にすることができます。 FQDNまたはそのサブセットの使用を強くお勧めします。ノード名TLVの最大長は255オクテットです。
The Value field is encoded in 7-bit ASCII. If a user interface for configuring or displaying this field permits Unicode characters, that user interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in [RFC5890] to achieve the correct format for transmission or display.
値フィールドは7ビットASCIIでエンコードされます。このフィールドを構成または表示するためのユーザーインターフェイスがUnicode文字を許可する場合、そのユーザーインターフェイスは、[RFC5890]で説明されているように、ToASCIIまたはToUnicodeアルゴリズムを適用して、送信または表示の正しい形式を実現します。
Although [RFC5301] describes an IS-IS-specific extension, usage of the Node Name TLV is possible for all protocols. How a router derives and injects node names, e.g., OSPF nodes, is outside of the scope of this document.
[RFC5301]はIS-IS固有の拡張について説明していますが、ノード名TLVの使用はすべてのプロトコルで可能です。ルーターがノード名（OSPFノードなど）を取得して挿入する方法は、このドキュメントの範囲外です。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Node Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Node Name Format
図17：ノード名の形式
The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary Router-IDs that the IGP might be using, e.g., for TE and migration purposes such as correlating a Node-ID between different protocols. If there is more than one auxiliary Router-ID of a given type, then each one is encoded in its own TLV.
ローカルIPv4 / IPv6ルーターID TLVは、TEや、異なるプロトコル間でノードIDを関連付けるなどの移行の目的で、IGPが使用している可能性のある補助ルーターIDを記述するために使用されます。特定のタイプの補助ルーターIDが複数ある場合は、それぞれが独自のTLVにエンコードされます。
The Opaque Node Attribute TLV is an envelope that transparently carries optional Node Attribute TLVs advertised by a router. An originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field or new protocol extensions to the protocol as advertised in the NLRI header Protocol-ID field for which there is no protocol-neutral representation in the BGP Link-State NLRI. The primary use of the Opaque Node Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the protocol-neutral BGP-LS extensions being published. A router, for example, could use this extension in order to advertise the native protocol's Node Attribute TLVs, such as the OSPF Router Informational Capabilities TLV defined in [RFC7770] or the IGP TE Node Capability Descriptor TLV described in [RFC5073].
不透明なノード属性TLVは、ルーターによってアドバタイズされるオプションのノード属性TLVを透過的に運ぶエンベロープです。発信元ルーターは、NLRIヘッダーのプロトコルIDフィールドでアドバタイズされたプロトコルに固有の情報をエンコードするためにこのTLVを使用するか、NLRIヘッダーのプロトコルIDフィールドでアドバタイズされたプロトコルに対する新しいプロトコル拡張で、プロトコル中立表現がないBGPリンクステートNLRI。不透明ノード属性TLVの主な用途は、たとえば、定義されている新しいIGPリンク状態属性と公開されているプロトコル中立のBGP-LS拡張との間のドキュメントラグを埋めることです。たとえば、ルーターはこの拡張を使用して、[RFC7770]で定義されているOSPFルーター情報機能TLVや[RFC5073]で説明されているIGP TEノード機能記述子TLVなどのネイティブプロトコルのノード属性TLVをアドバタイズできます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque node attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Opaque Node Attribute Format
図18：不透明なノード属性の形式
Link Attribute TLVs are TLVs that may be encoded in the BGP-LS attribute with a Link NLRI. Each 'Link Attribute' is a Type/Length/ Value (TLV) triplet formatted as defined in Section 3.1. The format and semantics of the Value fields in some Link Attribute TLVs correspond to the format and semantics of the Value fields in IS-IS Extended IS Reachability sub-TLVs, defined in [RFC5305] and [RFC5307]. Other Link Attribute TLVs are defined in this document. Although the encodings for Link Attribute TLVs were originally defined for IS-IS, the TLVs can carry data sourced by either IS-IS or OSPF.
リンク属性TLVは、リンクNLRIを使用してBGP-LS属性にエンコードできるTLVです。各「リンク属性」は、セクション3.1で定義された形式のタイプ/長さ/値（TLV）トリプレットです。一部のリンク属性TLVの値フィールドのフォーマットとセマンティクスは、[RFC5305]と[RFC5307]で定義されているIS-IS拡張IS到達可能性サブTLVの値フィールドのフォーマットとセマンティクスに対応しています。このドキュメントでは、他のリンク属性TLVが定義されています。リンク属性TLVのエンコーディングは元々IS-IS用に定義されていましたが、TLVはIS-ISまたはOSPFのいずれかから供給されたデータを伝送できます。
The following Link Attribute TLVs are valid in the BGP-LS attribute with a Link NLRI:
次のリンク属性TLVは、リンクNLRIを使用するBGP-LS属性で有効です。
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 |
| | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
| | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 3.3.2.5 |
| | Group | | |
| 1097 | Opaque Link | --- | Section 3.3.2.6 |
| | Attribute | | |
| 1098 | Link Name | --- | Section 3.3.2.7 |
+-----------+---------------------+--------------+------------------+
Table 9: Link Attribute TLVs
表9：リンク属性TLV
The local/remote IPv4/IPv6 Router-ID TLVs are used to describe auxiliary Router-IDs that the IGP might be using, e.g., for TE purposes. All auxiliary Router-IDs of both the local and the remote node MUST be included in the link attribute of each Link NLRI. If there is more than one auxiliary Router-ID of a given type, then multiple TLVs are used to encode them.
ローカル/リモートIPv4 / IPv6ルーターID TLVは、IGPがTEの目的などで使用している可能性のある補助ルーターIDを記述するために使用されます。ローカルノードとリモートノードの両方のすべての補助ルーターIDは、各リンクNLRIのリンク属性に含まれている必要があります。特定のタイプの補助ルーターIDが複数ある場合、それらをエンコードするために複数のTLVが使用されます。
The MPLS Protocol Mask TLV carries a bit mask describing which MPLS signaling protocols are enabled. The length of this TLV is 1. The value is a bit array of 8 flags, where each bit represents an MPLS Protocol capability.
MPLSプロトコルマスクTLVは、どのMPLSシグナリングプロトコルが有効になっているかを示すビットマスクを伝送します。このTLVの長さは1です。値は8つのフラグのビット配列で、各ビットはMPLSプロトコル機能を表します。
Generation of the MPLS Protocol Mask TLV is only valid for and SHOULD only be used with originators that have local link insight, for example, the Protocol-IDs 'Static configuration' or 'Direct' as per Table 2. The MPLS Protocol Mask TLV MUST NOT be included in NLRIs with the other Protocol-IDs listed in Table 2.
MPLSプロトコルマスクTLVの生成は有効であり、SHOULDは、ローカルリンクの洞察を持つ発信者、たとえば、表2のように、プロトコルIDの「静的構成」または「直接」でのみ使用する必要があります。MPLSプロトコルマスクTLVは、表2にリストされている他のプロトコルIDを持つNLRIには含まれません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|R| Reserved |
+-+-+-+-+-+-+-+-+
Figure 19: MPLS Protocol Mask TLV
図19：MPLSプロトコルマスクTLV
The following bits are defined:
次のビットが定義されています。
+------------+------------------------------------------+-----------+
| Bit | Description | Reference |
+------------+------------------------------------------+-----------+
| 'L' | Label Distribution Protocol (LDP) | [RFC5036] |
| 'R' | Extension to RSVP for LSP Tunnels | [RFC3209] |
| | (RSVP-TE) | |
| 'Reserved' | Reserved for future use | |
+------------+------------------------------------------+-----------+
Table 10: MPLS Protocol Mask TLV Codes
表10：MPLSプロトコルマスクTLVコード
The TE Default Metric TLV carries the Traffic Engineering metric for this link. The length of this TLV is fixed at 4 octets. If a source protocol uses a metric width of less than 32 bits, then the high-order bits of this field MUST be padded with zero.
TEデフォルトメトリックTLVは、このリンクのトラフィックエンジニアリングメトリックを伝送します。このTLVの長さは4オクテットに固定されています。ソースプロトコルが32ビット未満のメトリック幅を使用する場合、このフィールドの上位ビットにはゼロを埋め込む必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Default Link Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: TE Default Metric TLV Format
図20：TEのデフォルトメトリックTLV形式
The IGP Metric TLV carries the metric for this link. The length of this TLV is variable, depending on the metric width of the underlying protocol. IS-IS small metrics have a length of 1 octet (the two most significant bits are ignored). OSPF link metrics have a length of 2 octets. IS-IS wide metrics have a length of 3 octets.
IGPメトリックTLVは、このリンクのメトリックを伝送します。このTLVの長さは、基礎となるプロトコルのメトリック幅に応じて可変です。 IS-ISの小さなメトリックの長さは1オクテットです（最上位の2ビットは無視されます）。 OSPFリンクメトリックの長さは2オクテットです。 IS-IS全体のメトリックの長さは3オクテットです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IGP Link Metric (variable length) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: IGP Metric TLV Format
図21：IGPメトリックTLV形式
The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link Group information (see Section 2.3 ("Shared Risk Link Group Information") of [RFC4202]). It contains a data structure consisting of a (variable) list of SRLG values, where each element in the list has 4 octets, as shown in Figure 22. The length of this TLV is 4 * (number of SRLG values).
共有リスクリンクグループ（SRLG）TLVは、共有リスクリンクグループ情報を伝達します（[RFC4202]のセクション2.3（「共有リスクリンクグループ情報」）を参照）。これには、図22に示すように、SRLG値の（変数）リストで構成されるデータ構造が含まれます。リストの各要素は4オクテットです。このTLVの長さは4 *（SRLG値の数）です。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ............ //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Shared Risk Link Group TLV Format
図22：共有リスクリンクグループTLV形式
The SRLG TLV for OSPF-TE is defined in [RFC4203]. In IS-IS, the SRLG information is carried in two different TLVs: the IPv4 (SRLG) TLV (Type 138) defined in [RFC5307] and the IPv6 SRLG TLV (Type 139) defined in [RFC6119]. In Link-State NLRI, both IPv4 and IPv6 SRLG information are carried in a single TLV.
OSPF-TEのSRLG TLVは[RFC4203]で定義されています。 IS-ISでは、SRLG情報は2つの異なるTLVで伝達されます。[RFC5307]で定義されたIPv4（SRLG）TLV（タイプ138）と[RFC6119]で定義されたIPv6 SRLG TLV（タイプ139）です。リンクステートNLRIでは、IPv4とIPv6の両方のSRLG情報が単一のTLVで伝送されます。
The Opaque Link Attribute TLV is an envelope that transparently carries optional Link Attribute TLVs advertised by a router. An originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field or new protocol extensions to the protocol as advertised in the NLRI header Protocol-ID field for which there is no protocol-neutral representation in the BGP Link-State NLRI. The primary use of the Opaque Link Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the 'protocol-neutral' BGP-LS extensions being published.
不透明リンク属性TLVは、ルーターによってアドバタイズされるオプションのリンク属性TLVを透過的に運ぶエンベロープです。発信元ルーターは、NLRIヘッダーのプロトコルIDフィールドでアドバタイズされたプロトコルに固有の情報をエンコードするためにこのTLVを使用するか、NLRIヘッダーのプロトコルIDフィールドでアドバタイズされたプロトコルに対する新しいプロトコル拡張で、プロトコル中立表現がないBGPリンクステートNLRI。不透明リンク属性TLVの主な用途は、たとえば、定義されている新しいIGPリンク状態属性と公開されている「プロトコル中立」のBGP-LS拡張との間のドキュメントラグを埋めることです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque link attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Opaque Link Attribute TLV Format
図23：不透明なリンク属性TLV形式
The Link Name TLV is optional. The Value field identifies the symbolic name of the router link. This symbolic name can be the FQDN for the link, it can be a subset of the FQDN, or it can be any string operators want to use for the link. The use of FQDN or a subset of it is strongly RECOMMENDED. The maximum length of the Link Name TLV is 255 octets.
リンク名TLVはオプションです。 「値」フィールドは、ルーター・リンクの記号名を識別します。このシンボリック名は、リンクのFQDN、FQDNのサブセット、またはリンクに使用する任意の文字列演算子にすることができます。 FQDNまたはそのサブセットの使用を強くお勧めします。リンク名TLVの最大長は255オクテットです。
The Value field is encoded in 7-bit ASCII. If a user interface for configuring or displaying this field permits Unicode characters, that user interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in [RFC5890] to achieve the correct format for transmission or display.
値フィールドは7ビットASCIIでエンコードされます。このフィールドを構成または表示するためのユーザーインターフェイスがUnicode文字を許可する場合、そのユーザーインターフェイスは、[RFC5890]で説明されているように、ToASCIIまたはToUnicodeアルゴリズムを適用して、送信または表示の正しい形式を実現します。
How a router derives and injects link names is outside of the scope of this document.
ルーターがリンク名を取得して挿入する方法は、このドキュメントの範囲外です。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Link Name TLV Format
図24：リンク名TLV形式
Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set of IGP attributes (such as metric, route tags, etc.) that MUST be reflected into the BGP-LS attribute with a prefix NLRI. This section describes the different attributes related to the IPv4/IPv6 prefixes. Prefix Attribute TLVs SHOULD be used when advertising NLRI types 3 and 4 only. The following Prefix Attribute TLVs are defined:
プレフィックスは、プレフィックスNLRIを使用してBGP-LS属性に反映する必要がある一連のIGP属性（メトリック、ルートタグなど）を使用してIGPトポロジ（IS-ISまたはOSPF）から学習されます。このセクションでは、IPv4 / IPv6プレフィックスに関連するさまざまな属性について説明します。接頭辞属性TLVは、NLRIタイプ3および4のみをアドバタイズするときに使用する必要があります（SHOULD）。次のプレフィックス属性TLVが定義されています。
+---------------+----------------------+----------+-----------------+
| TLV Code | Description | Length | Reference |
| Point | | | |
+---------------+----------------------+----------+-----------------+
| 1152 | IGP Flags | 1 | Section 3.3.3.1 |
| 1153 | IGP Route Tag | 4*n | [RFC5130] |
| 1154 | IGP Extended Route | 8*n | [RFC5130] |
| | Tag | | |
| 1155 | Prefix Metric | 4 | [RFC5305] |
| 1156 | OSPF Forwarding | 4 | [RFC2328] |
| | Address | | |
| 1157 | Opaque Prefix | variable | Section 3.3.3.6 |
| | Attribute | | |
+---------------+----------------------+----------+-----------------+
Table 11: Prefix Attribute TLVs
表11：プレフィックス属性TLV
The IGP Flags TLV contains IS-IS and OSPF flags and bits originally assigned to the prefix. The IGP Flags TLV is encoded as follows:
IGPフラグTLVには、IS-ISおよびOSPFフラグと、最初にプレフィックスに割り当てられたビットが含まれています。 IGPフラグ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|N|L|P| Resvd.|
+-+-+-+-+-+-+-+-+
Figure 25: IGP Flag TLV Format
図25：IGPフラグTLV形式
The Value field contains bits defined according to the table below:
値フィールドには、以下の表に従って定義されたビットが含まれています。
+----------+---------------------------+-----------+
| Bit | Description | Reference |
+----------+---------------------------+-----------+
| 'D' | IS-IS Up/Down Bit | [RFC5305] |
| 'N' | OSPF "no unicast" Bit | [RFC5340] |
| 'L' | OSPF "local address" Bit | [RFC5340] |
| 'P' | OSPF "propagate NSSA" Bit | [RFC5340] |
| Reserved | Reserved for future use. | |
+----------+---------------------------+-----------+
Table 12: IGP Flag Bits Definitions
表12：IGPフラグビットの定義
The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or OSPF) of the prefix and is encoded as follows:
IGPルートタグTLVは、プレフィックスの元のIGPタグ（IS-IS [RFC5130]またはOSPF）を伝送し、次のようにエンコードされます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Route Tags (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: IGP Route Tag TLV Format
図26：IGPルートタグTLV形式
Length is a multiple of 4.
長さは4の倍数です。
The Value field contains one or more Route Tags as learned in the IGP topology.
[Value]フィールドには、IGPトポロジで学習された1つ以上のルートタグが含まれています。
The Extended IGP Route Tag TLV carries IS-IS Extended Route Tags of the prefix [RFC5130] and is encoded as follows:
拡張IGPルートタグTLVは、プレフィックス[RFC5130]のIS-IS拡張ルートタグを伝達し、次のようにエンコードされます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Route Tag (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Extended IGP Route Tag TLV Format
図27：拡張IGPルートタグTLV形式
Length is a multiple of 8.
長さは8の倍数です。
The Extended Route Tag field contains one or more Extended Route Tags as learned in the IGP topology.
[拡張ルートタグ]フィールドには、IGPトポロジで学習された1つ以上の拡張ルートタグが含まれています。
The Prefix Metric TLV is an optional attribute and may only appear once. If present, it carries the metric of the prefix as known in the IGP topology as described in Section 4 of [RFC5305] (and therefore represents the reachability cost to the prefix). If not present, it means that the prefix is advertised without any reachability.
プレフィックスメトリックTLVはオプションの属性であり、1回のみ表示できます。存在する場合は、[RFC5305]のセクション4で説明されているように、IGPトポロジで知られているプレフィックスのメトリックを伝送します（したがって、プレフィックスへの到達可能性コストを表します）。存在しない場合、プレフィックスは到達不能でアドバタイズされます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Prefix Metric TLV Format
図28：プレフィックスメトリックTLV形式
Length is 4.
長さは4です。
The OSPF Forwarding Address TLV [RFC2328] [RFC5340] carries the OSPF forwarding address as known in the original OSPF advertisement. Forwarding address can be either IPv4 or IPv6.
OSPF転送アドレスTLV [RFC2328] [RFC5340]は、元のOSPFアドバタイズメントで知られているように、OSPF転送アドレスを伝送します。転送アドレスはIPv4またはIPv6のいずれかです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Forwarding Address (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OSPF Forwarding Address TLV Format
図29：OSPF転送アドレスTLV形式
Length is 4 for an IPv4 forwarding address, and 16 for an IPv6 forwarding address.
長さは、IPv4転送アドレスの場合は4、IPv6転送アドレスの場合は16です。
The Opaque Prefix Attribute TLV is an envelope that transparently carries optional Prefix Attribute TLVs advertised by a router. An originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field or new protocol extensions to the protocol as advertised in the NLRI header Protocol-ID field for which there is no protocol-neutral representation in the BGP Link-State NLRI. The primary use of the Opaque Prefix Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the protocol-neutral BGP-LS extensions being published.
不透明なプレフィックス属性TLVは、ルーターによってアドバタイズされるオプションのプレフィックス属性TLVを透過的に運ぶエンベロープです。発信元ルーターは、NLRIヘッダーのプロトコルIDフィールドでアドバタイズされたプロトコルに固有の情報をエンコードするためにこのTLVを使用するか、NLRIヘッダーのプロトコルIDフィールドでアドバタイズされたプロトコルに対する新しいプロトコル拡張で、プロトコル中立表現がないBGPリンクステートNLRI。不透明プレフィックス属性TLVの主な用途は、たとえば、定義されている新しいIGPリンク状態属性と公開されているプロトコル中立のBGP-LS拡張の間のドキュメントラグを埋めることです。
The format of the TLV is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque Prefix Attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Opaque Prefix Attribute TLV Format
図30：不透明プレフィックス属性のTLV形式
Type is as specified in Table 11. Length is variable.
タイプは表11で指定されたとおりです。長さは可変です。
BGP link-state information for both IPv4 and IPv6 networks can be carried over either an IPv4 BGP session or an IPv6 BGP session. If an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. Usually, the next hop will be set to the local endpoint address of the BGP session. The next-hop address MUST be encoded as described in [RFC4760]. The Length field of the next-hop address will specify the next-hop address family. If the next-hop length is 4, then the next hop is an IPv4 address; if the next-hop length is 16, then it is a global IPv6 address; and if the next-hop length is 32, then there is one global IPv6 address followed by a link-local IPv6 address. The link-local IPv6 address should be used as described in [RFC2545]. For VPN Subsequent Address Family Identifier (SAFI), as per custom, an 8-byte Route Distinguisher set to all zero is prepended to the next hop.
IPv4ネットワークとIPv6ネットワークの両方のBGPリンク状態情報は、IPv4 BGPセッションまたはIPv6 BGPセッションのいずれかを介して伝送できます。 IPv4 BGPセッションが使用される場合、MP_REACH_NLRIのネクストホップはIPv4アドレスである必要があります（SHOULD）。同様に、IPv6 BGPセッションが使用される場合、MP_REACH_NLRIのネクストホップはIPv6アドレスである必要があります（SHOULD）。通常、ネクストホップはBGPセッションのローカルエンドポイントアドレスに設定されます。ネクストホップアドレスは、[RFC4760]で説明されているようにエンコードする必要があります。ネクストホップアドレスの長さフィールドは、ネクストホップアドレスファミリを指定します。ネクストホップの長さが4の場合、ネクストホップはIPv4アドレスです。ネクストホップの長さが16の場合、それはグローバルIPv6アドレスです。ネクストホップの長さが32の場合、グローバルIPv6アドレスが1つあり、その後にリンクローカルIPv6アドレスが続きます。 [RFC2545]で説明されているように、リンクローカルIPv6アドレスを使用する必要があります。 VPN後続アドレスファミリ識別子（SAFI）の場合、カスタムに従って、すべてゼロに設定された8バイトのルート識別子が次のホップの先頭に追加されます。
The BGP Next Hop attribute is used by each BGP-LS speaker to validate the NLRI it receives. In case identical NLRIs are sourced by multiple originators, the BGP Next Hop attribute is used to tiebreak as per the standard BGP path decision process. This specification doesn't mandate any rule regarding the rewrite of the BGP Next Hop attribute.
BGPネクストホップ属性は、各BGP-LSスピーカーが、受信するNLRIを検証するために使用されます。同一のNLRIが複数の発信元から供給されている場合は、BGPネクストホップ属性を使用して、標準のBGPパス決定プロセスに従ってタイブレークを行います。この仕様では、BGPネクストホップ属性の書き換えに関する規則は義務付けられていません。
The main source of TE information is the IGP, which is not active on inter-AS links. In some cases, the IGP may have information of inter-AS links [RFC5392] [RFC5316]. In other cases, an implementation SHOULD provide a means to inject inter-AS links into BGP-LS. The exact mechanism used to provision the inter-AS links is outside the scope of this document
TE情報の主なソースはIGPであり、AS間リンクではアクティブではありません。場合によっては、IGPにAS間リンクの情報がある場合があります[RFC5392] [RFC5316]。他の場合では、実装は、AS間リンクをBGP-LSに挿入する手段を提供する必要があります（SHOULD）。 AS間リンクのプロビジョニングに使用される正確なメカニズムは、このドキュメントの範囲外です。
Encoding of a broadcast LAN in IS-IS provides a good example of how Router-IDs are encoded. Consider Figure 31. This represents a Broadcast LAN between a pair of routers. The "real" (non-pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for the LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1, Node2) are being generated.
IS-ISでのブロードキャストLANのエンコードは、ルーターIDのエンコード方法の良い例です。図31を検討してください。これは、1組のルーター間のブロードキャストLANを表しています。 「実際の」（非疑似ノード）ルーターには、IPv4ルーターIDとIS-ISノードIDの両方があります。疑似ノードにはIPv4ルーターIDがありません。 Node1はLANのDISです。 2つの単方向リンク（Node1、Pseudonode1）および（Pseudonode1、Node2）が生成されています。
The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The IGP Router-ID TLV of the local Node Descriptor is 6 octets long and contains the ISO-ID of Node1, 1920.0000.2001. The IGP Router-ID TLV of the remote Node Descriptor is 7 octets long and contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link contains one local IPv4 Router-ID TLV (TLV type 1028) containing 192.0.2.1, the IPv4 Router-ID of Node1.
（Node1、Pseudonode1）のリンクNLRIは、次のようにエンコードされます。ローカルノード記述子のIGPルーターID TLVは6オクテットで、Node1 1920.0000.2001のISO-IDが含まれています。リモートノード記述子のIGPルーターID TLVは7オクテット長で、Pseudonode1、1920.0000.2001.02のISO-IDが含まれています。このリンクのBGP-LS属性には、192.0.2.1、Node1のIPv4ルーターIDを含む1つのローカルIPv4ルーターID TLV（TLVタイプ1028）が含まれています。
The Link NLRI of (Pseudonode1, Node2) is encoded as follows. The IGP Router-ID TLV of the local Node Descriptor is 7 octets long and contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The IGP Router-ID TLV of the remote Node Descriptor is 6 octets long and contains the ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of this link contains one remote IPv4 Router-ID TLV (TLV type 1030) containing 192.0.2.2, the IPv4 Router-ID of Node2.
（Pseudonode1、Node2）のリンクNLRIは、次のようにエンコードされます。ローカルノード記述子のIGPルーターID TLVは7オクテットで、Pseudonode1、1920.0000.2001.02のISO-IDが含まれています。リモートノード記述子のIGPルーターID TLVは6オクテット長で、Node2のISO-ID 1920.0000.2002が含まれています。このリンクのBGP-LS属性には、192.0.2.2（Node2のIPv4ルーターID）を含む1つのリモートIPv4ルーターID TLV（TLVタイプ1030）が含まれています。
+-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 |
|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
| 192.0.2.1 | | | | 192.0.2.2 |
+-----------------+ +-----------------+ +-----------------+
Figure 31: IS-IS Pseudonodes
図31：IS-IS疑似ノード
Encoding of a broadcast LAN in OSPF provides a good example of how Router-IDs and local Interface IPs are encoded. Consider Figure 32. This represents a Broadcast LAN between a pair of routers. The "real" (non-pseudonode) routers have both an IPv4 Router-ID and an Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 Interface Address (for disambiguation), and an OSPF Area. Node1 is the DR for the LAN; hence, its local IP address 10.1.1.1 is used as both the Router-ID and Interface IP for the pseudonode keys. Two unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2), are being generated.
OSPFでのブロードキャストLANのエンコードは、ルーターIDとローカルインターフェイスIPのエンコード方法の良い例です。図32を検討してください。これは、1組のルーター間のブロードキャストLANを表しています。 「実際の」（非疑似ノード）ルーターには、IPv4ルーターIDとエリア識別子の両方があります。疑似ノードには、IPv4ルーターID、IPv4インターフェースアドレス（一義化のため）、およびOSPFエリアがあります。 Node1はLANのDRです。したがって、そのローカルIPアドレス10.1.1.1は、疑似ノードキーのルーターIDとインターフェイスIPの両方として使用されます。 2つの単方向リンク（Node1、Pseudonode1）および（Pseudonode1、Node2）が生成されています。
The Link NLRI of (Node1, Pseudonode1) is encoded as follows:
（Node1、Pseudonode1）のリンクNLRIは、次のようにエンコードされます。
o Local Node Descriptor
o ローカルノード記述子
TLV #515: IGP Router-ID: 11.11.11.11
TLV #514: OSPF Area-ID: ID:0.0.0.0
o Remote Node Descriptor
o リモートノード記述子
TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1
TLV #514: OSPF Area-ID: ID:0.0.0.0
The Link NLRI of (Pseudonode1, Node2) is encoded as follows:
（Pseudonode1、Node2）のリンクNLRIは、次のようにエンコードされます。
o Local Node Descriptor
o ローカルノード記述子
TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1
TLV #514: OSPF Area-ID: ID:0.0.0.0
o Remote Node Descriptor
o リモートノード記述子
TLV #515: IGP Router-ID: 33.33.33.34
TLV #514: OSPF Area-ID: ID:0.0.0.0
+-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 |
| 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 |
| | | 10.1.1.1 | | |
| Area 0 | | Area 0 | | Area 0 |
+-----------------+ +-----------------+ +-----------------+
Figure 32: OSPF Pseudonodes
図32：OSPF疑似ノード
Graceful migration from one IGP to another requires coordinated operation of both protocols during the migration period. Such a coordination requires identifying a given physical link in both IGPs. The IPv4 Router-ID provides that "glue", which is present in the Node Descriptors of the OSPF Link NLRI and in the link attribute of the IS-IS Link NLRI.
あるIGPから別のIGPへの正常な移行には、移行期間中に両方のプロトコルの調整された操作が必要です。このような調整では、両方のIGPで特定の物理リンクを識別する必要があります。 IPv4ルーターIDは、OSPFリンクNLRIのノード記述子とIS-ISリンクNLRIのリンク属性に存在する「接着剤」を提供します。
Consider a point-to-point link between two routers, A and B, that initially were OSPFv2-only routers and then IS-IS is enabled on them. Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 Router-ID, and ISO-ID. Each protocol generates one Link NLRI for the link (A, B), both of which are carried by BGP-LS. The OSPFv2 Link NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B in the local and remote Node Descriptors, respectively. The IS-IS Link NLRI for the link is encoded with the ISO-ID of nodes A and B in the local and remote Node Descriptors, respectively. In addition, the BGP-LS attribute of the IS-IS Link NLRI contains the TLV type 1028 containing the IPv4 Router-ID of node A, TLV type 1030 containing the IPv4 Router-ID of node B, and TLV type 1031 containing the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, the link (A, B) can be identified in both the IS-IS and OSPF protocol.
最初はOSPFv2のみのルーターでしたが、次にIS-ISが有効になっている2つのルーターAとBの間のポイントツーポイントリンクについて考えてみます。ノードAにはIPv4ルーターIDとISO-IDがあります。ノードBには、IPv4ルーターID、IPv6ルーターID、およびISO-IDがあります。各プロトコルは、リンク（A、B）に対して1つのリンクNLRIを生成します。どちらもBGP-LSによって伝送されます。リンクのOSPFv2リンクNLRIは、ローカルおよびリモートノード記述子のノードAおよびBのIPv4ルーターIDでそれぞれエンコードされます。リンクのIS-ISリンクNLRIは、ローカルおよびリモートノード記述子のノードAおよびBのISO-IDでそれぞれエンコードされます。さらに、IS-ISリンクNLRIのBGP-LS属性には、ノードAのIPv4ルーターIDを含むTLVタイプ1028、ノードBのIPv4ルーターIDを含むTLVタイプ1030、およびIPv6を含むTLVタイプ1031が含まれます。ノードBのルーターID。この場合、IPv4ルーターIDを使用すると、IS-ISプロトコルとOSPFプロトコルの両方でリンク（A、B）を識別できます。
Distribution of all links available in the global Internet is certainly possible; however, it not desirable from a scaling and privacy point of view. Therefore, an implementation may support a link to path aggregation. Rather than advertising all specific links of a domain, an ASBR may advertise an "aggregate link" between a non-adjacent pair of nodes. The "aggregate link" represents the aggregated set of link properties between a pair of non-adjacent nodes. The actual methods to compute the path properties (of bandwidth, metric, etc.) are outside the scope of this document. The decision whether to advertise all specific links or aggregated links is an operator's policy choice. To highlight the varying levels of exposure, the following deployment examples are discussed.
グローバルインターネットで利用可能なすべてのリンクの配布は確かに可能です。ただし、スケーリングとプライバシーの観点からは望ましくありません。したがって、実装はパス集約へのリンクをサポートする場合があります。 ASBRは、ドメインのすべての特定のリンクをアドバタイズするのではなく、隣接していないノードのペア間の「集約リンク」をアドバタイズします。 「集約リンク」は、隣接していないノードのペア間のリンクプロパティの集約されたセットを表します。 （帯域幅、メトリックなどの）パスプロパティを計算する実際の方法は、このドキュメントの範囲外です。すべての特定のリンクをアドバタイズするか、集約されたリンクをアドバタイズするかは、オペレーターのポリシーの選択です。さまざまなレベルの露出を強調するために、次の展開例について説明します。
Consider Figure 33. Both AS1 and AS2 operators want to protect their inter-AS {R1, R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to compute its link-protection LSP to R3, it needs to "see" an alternate path to R3. Therefore, the AS2 operator exposes its topology. All BGP-TE-enabled routers in AS1 "see" the full topology of AS2 and therefore can compute a backup path. Note that the computing router decides if the direct link between {R3, R4} or the {R4, R5, R3} path is used.
図33を検討してください。AS1とAS2の両方のオペレーターが、RSVP-FRR LSPを使用してAS間{R1、R3}、{R2、R4}リンクを保護したいと考えています。 R1がR3へのリンク保護LSPを計算する場合は、R3への代替パスを「見る」必要があります。したがって、AS2オペレーターはそのトポロジーを公開します。 AS1のすべてのBGP-TE対応ルーターは、AS2の完全なトポロジを「参照」するため、バックアップパスを計算できます。コンピューティングルータは、{R3、R4}または{R4、R5、R3}パス間の直接リンクを使用するかどうかを決定することに注意してください。
AS1 : AS2
:
R1-------R3
| : | \
| : | R5
| : | /
R2-------R4
:
:
Figure 33: No Link Aggregation
ふぃぐれ ３３： の ぃんｋ あっｇれがちおん
The brief difference between the "no-link aggregation" example and this example is that no specific link gets exposed. Consider Figure 34. The only link that gets advertised by AS2 is an "aggregate" link between R3 and R4. This is enough to tell AS1 that there is a backup path. However, the actual links being used are hidden from the topology.
「リンクなしの集約」の例とこの例の簡単な違いは、特定のリンクが公開されないことです。図34を検討してください。AS2によってアドバタイズされる唯一のリンクは、R3とR4の間の「集約」リンクです。これは、バックアップパスがあることをAS1に伝えるのに十分です。ただし、使用されている実際のリンクはトポロジから隠されています。
AS1 : AS2
:
R1-------R3
| : |
| : |
| : |
R2-------R4
:
:
Figure 34: ASBR Link Aggregation
図34：ASBRリンク集約
Service providers in control of multiple ASes may even decide to not expose their internal inter-AS links. Consider Figure 35. AS3 is modeled as a single node that connects to the border routers of the aggregated domain.
複数のASを制御するサービスプロバイダーは、内部のAS間リンクを公開しないことを決定することさえあります。図35を検討してください。AS3は、集約ドメインの境界ルーターに接続する単一ノードとしてモデル化されています。
AS1 : AS2 : AS3
: :
R1-------R3-----
| : : \
| : : vR0
| : : /
R2-------R4-----
: :
: :
Figure 35: Multi-AS Aggregation
図35：マルチAS集約
IANA has assigned address family number 16388 (BGP-LS) in the "Address Family Numbers" registry with this document as a reference.
IANAは、このドキュメントを参照して、「アドレスファミリ番号」レジストリでアドレスファミリ番号16388（BGP-LS）を割り当てました。
IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the "SAFI Values" sub-registry under the "Subsequent Address Family Identifiers (SAFI) Parameters" registry.
IANAは、「後続のアドレスファミリ識別子（SAFI）パラメータ」レジストリの「SAFI値」サブレジストリで、SAFI値71（BGP-LS）および72（BGP-LS-VPN）を割り当てました。
IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path Attributes" sub-registry under the "Border Gateway Protocol (BGP) Parameters" registry.
IANAは、「ボーダーゲートウェイプロトコル（BGP）パラメーター」レジストリの下の「BGPパス属性」サブレジストリで値29（BGP-LS属性）を割り当てました。
IANA has created a new "Border Gateway Protocol - Link State (BGP-LS)
Parameters" registry at <http://www.iana.org/assignments/bgp-ls-
parameters>. All of the following registries are BGP-LS specific and
are accessible under this registry:
o "BGP-LS NLRI-Types" registry
Value 0 is reserved. The maximum value is 65535. The registry has been populated with the values shown in Table 1. Allocations within the registry require documentation of the proposed use of the allocated value (Specification Required) and approval by the Designated Expert assigned by the IESG (see [RFC5226]).
値0は予約されています。最大値は65535です。レジストリには表1に示す値が入力されています。レジストリ内の割り当てには、割り当てられた値の提案された使用の文書化（指定が必要）およびIESGによって割り当てられた指定専門家による承認が必要です（[ RFC5226]）。
o "BGP-LS Protocol-IDs" registry
o 「BGP-LS Protocol-IDs」レジストリ
Value 0 is reserved. The maximum value is 255. The registry has been populated with the values shown in Table 2. Allocations within the registry require documentation of the proposed use of the allocated value (Specification Required) and approval by the Designated Expert assigned by the IESG (see [RFC5226]).
値0は予約されています。最大値は255です。レジストリには、表2に示す値が入力されています。レジストリ内の割り当てには、割り当てられた値の提案された使用の文書化（指定が必要）およびIESGによって割り当てられた指定専門家による承認が必要です（[ RFC5226]）。
o "BGP-LS Well-Known Instance-IDs" registry
o 「BGP-LS既知のインスタンスID」レジストリ
The registry has been populated with the values shown in Table 3. New allocations from the range 1-31 use the IANA allocation policy "Specification Required" and require approval by the Designated Expert assigned by the IESG (see [RFC5226]). Values in the range 32 to 2^64-1 are for "Private Use" and are not recorded by IANA.
レジストリには、表3に示す値が入力されています。1-31の範囲からの新しい割り当ては、IANA割り当てポリシー「Specification Required」を使用し、IESGによって割り当てられたDesignated Expertによる承認が必要です（[RFC5226]を参照）。 32から2 ^ 64-1の範囲の値は「個人使用」用であり、IANAによって記録されません。
o "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry
o 「BGP-LSノード記述子、リンク記述子、プレフィックス記述子、および属性TLV」レジストリ
Values 0-255 are reserved. Values 256-65535 will be used for code points. The registry has been populated with the values shown in Table 13. Allocations within the registry require documentation of the proposed use of the allocated value (Specification Required) and approval by the Designated Expert assigned by the IESG (see [RFC5226]).
値0〜255は予約済みです。コードポイントには256〜65535の値が使用されます。レジストリには表13に示す値が入力されています。レジストリ内の割り当てには、割り当てられた値の提案された使用の文書化（仕様が必要）と、IESGによって割り当てられた指定専門家による承認が必要です（[RFC5226]を参照）。
In all cases of review by the Designated Expert (DE) described here, the DE is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC5226] and to verify that the document is permanently and publicly available. The DE is also expected to check the clarity of purpose and use of the requested code points. Last, the DE must verify that any specification produced in the IETF that requests one of these code points has been made available for review by the IDR working group and that any specification produced outside the IETF does not conflict with work that is active or already published within the IETF.
ここで説明されている指定専門家（DE）によるレビューのすべての場合において、DEは、[RFC5226]で説明されている適切な文書（仕様）の存在を確認し、その文書が永続的かつ一般に入手可能であることを確認する必要があります。 DEは、目的の明確さと要求されたコードポイントの使用を確認することも期待されています。最後に、DEは、これらのコードポイントの1つを要求するIETFで作成された仕様がIDRワーキンググループによるレビューに利用できること、およびIETFの外部で作成された仕様がアクティブまたは既に公開されている作業と競合しないことを確認する必要があります。 IETF内。
This section is structured as recommended in [RFC5706].
このセクションは、[RFC5706]で推奨されているように構成されています。
Existing BGP operational procedures apply. No new operation procedures are defined in this document. It is noted that the NLRI information present in this document carries purely application-level data that has no immediate corresponding forwarding state impact. As such, any churn in reachability information has a different impact than regular BGP updates, which need to change the forwarding state for an entire router. Furthermore, it is anticipated that distribution of this NLRI will be handled by dedicated route reflectors providing a level of isolation and fault containment between different NLRI types.
既存のBGP操作手順が適用されます。このドキュメントでは、新しい操作手順は定義されていません。このドキュメントにあるNLRI情報は、対応する転送状態に直接影響を与えない純粋なアプリケーションレベルのデータを運ぶことに注意してください。そのため、到達可能性情報のチャーンは、ルーター全体の転送状態を変更する必要がある通常のBGPアップデートとは異なる影響を及ぼします。さらに、このNLRIの配布は、さまざまなNLRIタイプ間の分離と障害抑制のレベルを提供する専用ルートリフレクタによって処理されることが予想されます。
Configuration parameters defined in Section 6.2.3 SHOULD be initialized to the following default values:
セクション6.2.3で定義されている構成パラメータは、次のデフォルト値に初期化する必要があります（SHOULD）。
o The Link-State NLRI capability is turned off for all neighbors.
o リンクステートNLRI機能は、すべてのネイバーに対してオフになっています。
o The maximum rate at which Link-State NLRIs will be advertised/ withdrawn from neighbors is set to 200 updates per second.
o リンクステートNLRIがアドバタイズ/ネイバーから撤回される最大レートは、毎秒200更新に設定されています。
The proposed extension is only activated between BGP peers after capability negotiation. Moreover, the extensions can be turned on/ off on an individual peer basis (see Section 6.2.3), so the extension can be gradually rolled out in the network.
提案された拡張機能は、機能ネゴシエーションの後にBGPピア間でのみアクティブ化されます。さらに、拡張機能は個々のピアごとにオン/オフを切り替えることができるため（セクション6.2.3を参照）、拡張機能をネットワークで段階的に展開できます。
The protocol extension defined in this document does not put new requirements on other protocols or functional components.
このドキュメントで定義されているプロトコル拡張は、他のプロトコルまたは機能コンポーネントに新しい要件を課しません。
Frequency of Link-State NLRI updates could interfere with regular BGP prefix distribution. A network operator MAY use a dedicated Route-Reflector infrastructure to distribute Link-State NLRIs.
リンクステートNLRI更新の頻度は、通常のBGPプレフィックス配布に干渉する可能性があります。ネットワークオペレーターは、専用のルートリフレクターインフラストラクチャを使用して、リンクステートNLRIを配布できます。
Distribution of Link-State NLRIs SHOULD be limited to a single admin domain, which can consist of multiple areas within an AS or multiple ASes.
リンクステートNLRIの配布は、1つのASまたは複数のAS内の複数の領域で構成できる単一の管理ドメインに限定する必要があります（SHOULD）。
Existing BGP procedures apply. In addition, an implementation SHOULD allow an operator to:
既存のBGP手順が適用されます。さらに、実装はオペレーターが次のことを許可する必要があります。
o List neighbors with whom the speaker is exchanging Link-State NLRIs.
o 話者がリンクステートNLRIを交換しているネイバーをリストします。
The IDR working group has documented and continues to document parts of the Management Information Base and YANG models for managing and monitoring BGP speakers and the sessions between them. It is currently believed that the BGP session running BGP-LS is not substantially different from any other BGP session and can be managed using the same data models.
IDRワーキンググループは、BGPスピーカーとそれらの間のセッションを管理および監視するための管理情報ベースとYANGモデルの一部を文書化し、引き続き文書化しています。現在、BGP-LSを実行するBGPセッションは他のBGPセッションと実質的に違いはなく、同じデータモデルを使用して管理できると考えられています。
If an implementation of BGP-LS detects a malformed attribute, then it MUST use the 'Attribute Discard' action as per [RFC7606], Section 2.
BGP-LSの実装が不正な属性を検出した場合、[RFC7606]のセクション2に記載されている「属性破棄」アクションを使用する必要があります。
An implementation of BGP-LS MUST perform the following syntactic checks for determining if a message is malformed.
BGP-LSの実装は、メッセージが不正かどうかを判断するために、次の構文チェックを実行する必要があります。
o Does the sum of all TLVs found in the BGP-LS attribute correspond to the BGP-LS path attribute length?
o BGP-LS属性にあるすべてのTLVの合計は、BGP-LSパス属性の長さに対応していますか？
o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute correspond to the BGP MP_REACH_NLRI length?
o BGP MP_REACH_NLRI属性にあるすべてのTLVの合計は、BGP MP_REACH_NLRIの長さに対応していますか？
o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI attribute correspond to the BGP MP_UNREACH_NLRI length?
o BGP MP_UNREACH_NLRI属性にあるすべてのTLVの合計は、BGP MP_UNREACH_NLRIの長さに対応していますか？
o Does the sum of all TLVs found in a Node, Link or Prefix Descriptor NLRI attribute correspond to the Total NLRI Length field of the Node, Link, or Prefix Descriptors?
o ノード、リンク、またはプレフィックス記述子のNLRI属性で検出されたすべてのTLVの合計は、ノード、リンク、またはプレフィックス記述子の[合計NLRI長]フィールドに対応していますか？
o Does any fixed-length TLV correspond to the TLV Length field in this document?
o このドキュメントのTLV長フィールドに対応する固定長TLVはありますか？
An implementation SHOULD allow the operator to specify neighbors to which Link-State NLRIs will be advertised and from which Link-State NLRIs will be accepted.
実装では、オペレーターは、リンクステートNLRIがアドバタイズされ、リンクステートNLRIが受け入れられるネイバーを指定できます。
An implementation SHOULD allow the operator to specify the maximum rate at which Link-State NLRIs will be advertised/withdrawn from neighbors.
実装は、オペレーターがリンクステートNLRIが近隣からアドバタイズ/撤回される最大レートを指定できるようにする必要があります（SHOULD）。
An implementation SHOULD allow the operator to specify the maximum number of Link-State NLRIs stored in a router's Routing Information Base (RIB).
実装は、オペレーターがルーターのルーティング情報ベース（RIB）に保存されるリンクステートNLRIの最大数を指定できるようにする必要があります（SHOULD）。
An implementation SHOULD allow the operator to create abstracted topologies that are advertised to neighbors and create different abstractions for different neighbors.
実装は、オペレーターがネイバーにアドバタイズされる抽象化されたトポロジーを作成し、異なるネイバーに異なる抽象化を作成できるようにする必要があります。
An implementation SHOULD allow the operator to configure a 64-bit Instance-ID.
実装では、オペレーターが64ビットのインスタンスIDを構成できるようにする必要があります（SHOULD）。
An implementation SHOULD allow the operator to configure a pair of ASN and BGP-LS identifiers (Section 3.2.1.4) per flooding set in which the node participates.
実装は、ノードが参加するフラッディングセットごとに、オペレーターがASNおよびBGP-LS識別子のペア（セクション3.2.1.4）を設定できるようにする必要があります（SHOULD）。
Not Applicable.
適用できません。
An implementation SHOULD provide the following statistics:
実装は、以下の統計を提供する必要があります（SHOULD）。
o Total number of Link-State NLRI updates sent/received
o 送受信されたリンクステートNLRI更新の総数
o Number of Link-State NLRI updates sent/received, per neighbor
o ネイバーごとに送受信されたリンクステートNLRIアップデートの数
o Number of errored received Link-State NLRI updates, per neighbor
o ネイバーごとのエラー受信リンク状態NLRI更新の数
o Total number of locally originated Link-State NLRIs
o ローカルで生成されたリンクステートNLRIの総数
These statistics should be recorded as absolute counts since system or session start time. An implementation MAY also enhance this information by recording peak per-second counts in each case.
これらの統計は、システムまたはセッションの開始時間からの絶対数として記録する必要があります。実装はまた、それぞれの場合の1秒あたりのピーク数を記録することにより、この情報を強化してもよい（MAY）。
An operator SHOULD define an import policy to limit inbound updates as follows:
オペレーターは、次のようにインバウンド更新を制限するインポートポリシーを定義する必要があります。
o Drop all updates from consumer peers.
o コンシューマピアからのすべての更新をドロップします。
An implementation MUST have the means to limit inbound updates.
実装には、インバウンド更新を制限する手段が必要です。
This section contains the global table of all TLVs/sub-TLVs defined in this document.
このセクションには、このドキュメントで定義されているすべてのTLV /サブTLVのグローバルテーブルが含まれています。
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV/ | Reference |
| Point | | Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 256 | Local Node | --- | Section 3.2.1.2 |
| | Descriptors | | |
| 257 | Remote Node | --- | Section 3.2.1.3 |
| | Descriptors | | |
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 |
| | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 |
| | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 |
| | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 |
| | address | | |
| 263 | Multi-Topology ID | --- | Section 3.2.1.5 |
| 264 | OSPF Route Type | --- | Section 3.2.3 |
| 265 | IP Reachability | --- | Section 3.2.3 |
| | Information | | |
| 512 | Autonomous System | --- | Section 3.2.1.4 |
| 513 | BGP-LS Identifier | --- | Section 3.2.1.4 |
| 514 | OSPF Area-ID | --- | Section 3.2.1.4 |
| 515 | IGP Router-ID | --- | Section 3.2.1.4 |
| 1024 | Node Flag Bits | --- | Section 3.3.1.1 |
| 1025 | Opaque Node | --- | Section 3.3.1.5 |
| | Attribute | | |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | |
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 |
| | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
| | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 3.3.2.5 |
| | Group | | |
| 1097 | Opaque Link | --- | Section 3.3.2.6 |
| | Attribute | | |
| 1098 | Link Name | --- | Section 3.3.2.7 |
| 1152 | IGP Flags | --- | Section 3.3.3.1 |
| 1153 | IGP Route Tag | --- | [RFC5130] |
| 1154 | IGP Extended Route | --- | [RFC5130] |
| | Tag | | |
| 1155 | Prefix Metric | --- | [RFC5305] |
| 1156 | OSPF Forwarding | --- | [RFC2328] |
| | Address | | |
| 1157 | Opaque Prefix | --- | Section 3.3.3.6 |
| | Attribute | | |
+-----------+---------------------+--------------+------------------+
Table 13: Summary Table of TLV/Sub-TLV Code Points
表13：TLV /サブTLVコードポイントの要約表
Procedures and protocol extensions defined in this document do not affect the BGP security model. See the Security Considerations section of [RFC4271] for a discussion of BGP security. Also refer to [RFC4272] and [RFC6952] for analysis of security issues for BGP.
このドキュメントで定義されている手順とプロトコル拡張は、BGPセキュリティモデルには影響しません。 BGPセキュリティの説明については、[RFC4271]のセキュリティに関する考慮事項のセクションを参照してください。 BGPのセキュリティ問題の分析については、[RFC4272]および[RFC6952]も参照してください。
In the context of the BGP peerings associated with this document, a BGP speaker MUST NOT accept updates from a consumer peer. That is, a participating BGP speaker should be aware of the nature of its relationships for link-state relationships and should protect itself from peers sending updates that either represent erroneous information feedback loops or are false input. Such protection can be achieved by manual configuration of consumer peers at the BGP speaker.
このドキュメントに関連するBGPピアリングのコンテキストでは、BGPスピーカーはコンシューマーピアからの更新を受け入れてはなりません（MUST NOT）。つまり、参加するBGPスピーカーは、リンク状態関係の関係の性質を認識し、誤った情報フィードバックループを表すか、誤った入力である更新を送信するピアから保護する必要があります。このような保護は、BGPスピーカーでコンシューマピアを手動で構成することで実現できます。
An operator SHOULD employ a mechanism to protect a BGP speaker against DDoS attacks from consumers. The principal attack a consumer may apply is to attempt to start multiple sessions either sequentially or simultaneously. Protection can be applied by imposing rate limits.
オペレーターは、消費者からのDDoS攻撃からBGPスピーカーを保護するメカニズムを採用する必要があります（SHOULD）。コンシューマが適用できる主な攻撃は、複数のセッションを順番にまたは同時に開始しようとすることです。レート制限を課すことで保護を適用できます。
Additionally, it may be considered that the export of link-state and TE information as described in this document constitutes a risk to confidentiality of mission-critical or commercially sensitive information about the network. BGP peerings are not automatic and require configuration; thus, it is the responsibility of the network operator to ensure that only trusted consumers are configured to receive such information.
さらに、このドキュメントに記載されているリンクステートおよびTE情報のエクスポートは、ネットワークに関するミッションクリティカルな情報または商業的に機密性の高い情報の機密性に対するリスクを構成すると見なされる場合があります。 BGPピアリングは自動ではなく、設定が必要です。したがって、信頼できるコンシューマのみがそのような情報を受信するように構成されていることを確認するのは、ネットワークオペレーターの責任です。
[ISO10589] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/ IEC 10589, November 2002.
[ISO10589]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムから中間システムのドメイン内ルーティング情報交換プロトコル」、ISO / IEC 10589、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, <http://www.rfc-editor.org/info/rfc2545>.
[RFC2545] Marques、P。およびF. Dupont、「Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing」、RFC 2545、DOI 10.17487 / RFC2545、1999年3月、<http：//www.rfc-editor。 org / info / rfc2545>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC4202] Kompella、K.、Ed。およびY. Rekhter編、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、DOI 10.17487 / RFC4202、2005年10月、<http://www.rfc-editor.org/info / rfc4202>。
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K.、Ed。およびY. Rekhter編、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<http://www.rfc-editor.org/info / rfc4203>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<http://www.rfc-editor.org/info/rfc4271>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<http：// www。 rfc-editor.org/info/rfc4760>。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <http://www.rfc-editor.org/info/rfc4915>.
[RFC4915] Psenak、P.、Mirtorabi、S.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「OSPFでのマルチトポロジ（MT）ルーティング」、RFC 4915、DOI 10.17487 / RFC4915、 2007年6月、<http://www.rfc-editor.org/info/rfc4915>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<http：// www。 rfc-editor.org/info/rfc5036>。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <http://www.rfc-editor.org/info/rfc5120>.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、DOI 10.17487 / RFC5120、 2008年2月、<http://www.rfc-editor.org/info/rfc5120>。
[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 2008, <http://www.rfc-editor.org/info/rfc5130>.
[RFC5130] Previdi、S.、Shand、M.、Ed。、およびC. Martin、「管理タグを使用したIS-ISのポリシー制御メカニズム」、RFC 5130、DOI 10.17487 / RFC5130、2008年2月、<http：/ /www.rfc-editor.org/info/rfc5130>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, October 2008, <http://www.rfc-editor.org/info/rfc5301>.
[RFC5301]マクファーソン、D。およびN.シェン、「IS-ISのダイナミックホスト名交換メカニズム」、RFC 5301、DOI 10.17487 / RFC5301、2008年10月、<http://www.rfc-editor.org/info/rfc5301 >。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305> 。
[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, <http://www.rfc-editor.org/info/rfc5307>.
[RFC5307] Kompella、K.、Ed。およびY. Rekhter編、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、DOI 10.17487 / RFC5307、2008年10月、<http://www.rfc-editor.org / info / rfc5307>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<http：//www.rfc-editor .org / info / rfc5340>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<http://www.rfc-editor.org/info/ rfc5890>。
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6119] Harrison、J.、Berger、J。、およびM. Bartlett、「IS-ISでのIPv6トラフィックエンジニアリング」、RFC 6119、DOI 10.17487 / RFC6119、2011年2月、<http：//www.rfc-editor。 org / info / rfc6119>。
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, <http://www.rfc-editor.org/info/rfc6549>.
[RFC6549] Lindem、A.、Roy、A。、およびS. Mirtorabi、「OSPFv2 Multi-Instance Extensions」、RFC 6549、DOI 10.17487 / RFC6549、2012年3月、<http://www.rfc-editor.org/ info / rfc6549>。
[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. Ward, "IS-IS Multi-Instance", RFC 6822, DOI 10.17487/RFC6822, December 2012, <http://www.rfc-editor.org/info/rfc6822>.
[RFC6822] Previdi、S.、Ed。、Ginsberg、L.、Shand、M.、Roy、A。、およびD. Ward、「IS-IS Multi-Instance」、RFC 6822、DOI 10.17487 / RFC6822、2012年12月、<http://www.rfc-editor.org/info/rfc6822>。
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.
[RFC7606] Chen、E。、編、Scudder、J。、編、Mohapatra、P。、およびK. Patel、「BGP UPDATEメッセージのエラー処理の改訂版」、RFC 7606、DOI 10.17487 / RFC7606、2015年8月、 <http://www.rfc-editor.org/info/rfc7606>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.
[RFC4272] Murphy、S。、「BGP Security Vulnerabilities Analysis」、RFC 4272、DOI 10.17487 / RFC4272、2006年1月、<http://www.rfc-editor.org/info/rfc4272>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<http://www.rfc-editor.org/info / rfc4364>。
[RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、JP。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<http：//www.rfc -editor.org/info/rfc4655>。
[RFC5073] Vasseur, JP., Ed. and JL. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, December 2007, <http://www.rfc-editor.org/info/rfc5073>.
[RFC5073] Vasseur、JP。、Ed。とJL。 Le Roux編、「トラフィックエンジニアリングノード機能の発見のためのIGPルーティングプロトコル拡張」、RFC 5073、DOI 10.17487 / RFC5073、2007年12月、<http://www.rfc-editor.org/info/rfc5073>。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、DOI 10.17487 / RFC5152、2008年2月、<http://www.rfc-editor.org/info/rfc5152>。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, <http://www.rfc-editor.org/info/rfc5316>.
[RFC5316] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするISIS拡張機能」、RFC 5316、DOI 10.17487 / RFC5316、2008年12月、< http://www.rfc-editor.org/info/rfc5316>。
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, <http://www.rfc-editor.org/info/rfc5392>.
[RFC5392] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするOSPF拡張機能」、RFC 5392、DOI 10.17487 / RFC5392、2009年1月、< http://www.rfc-editor.org/info/rfc5392>。
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>.
[RFC5693] Seedorf、J。およびE. Burger、「Application-Layer Traffic Optimization（ALTO）Problem Statement」、RFC 5693、DOI 10.17487 / RFC5693、2009年10月、<http://www.rfc-editor.org/info / rfc5693>。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>.
[RFC5706]ハリントン、D。、「新しいプロトコルとプロトコル拡張の操作と管理を考慮するためのガイドライン」、RFC 5706、DOI 10.17487 / RFC5706、2009年11月、<http://www.rfc-editor.org/info/rfc5706 >。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによるBGP、LDP、PCEP、およびMSDPの問題の分析」、RFC 6952、DOI 10.17487 / RFC6952、2013年5月、<http://www.rfc-editor.org/info/rfc6952>。
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285]アリミ、R。、編、Penno、R。、編、Yang、Y。、編、Kiesel、S.、Previdi、S.、Roome、W.、Shalunov、S.、R。 Woundy、「Application-Layer Traffic Optimization（ALTO）Protocol」、RFC 7285、DOI 10.17487 / RFC7285、2014年9月、<http://www.rfc-editor.org/info/rfc7285>。
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <http://www.rfc-editor.org/info/rfc7770>.
[RFC7770] Lindem、A.、Ed。、Shen、N.、Vasseur、JP。、Aggarwal、R.、and S. Shaffer、 "Extensions to OSPF for Advertising Optional Router Capabilities"、RFC 7770、DOI 10.17487 / RFC7770、 2016年2月、<http://www.rfc-editor.org/info/rfc7770>。
Acknowledgements
謝辞
We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and Ben Campbell for their comments.
Nischal Sheth、Alia Atlas、David Ward、Derek Yeung、Murtuza Lightwala、John Scudder、Kaliraj Vairavakkalai、Les Ginsberg、Liem Nguyen、Manish Bhardwaj、Matt Miller、Mike Shand、Peter Psenak、Rex Fernando、Richard Woundy、 Steven Luong、Tamas Mondal、Waqas Alam、Vipin Kumar、Naiming Shen、Carlos Pignataro、Balaji Rajagopalan、Yakov Rekhter、Alvaro Retana、Barry Leiba、Ben Campbellのコメント。
Contributors
貢献者
We would like to thank Robert Varga for the significant contribution he gave to this document.
この文書に多大な貢献をしてくれたRobert Vargaに感謝します。
Authors' Addresses
著者のアドレス
Hannes Gredler (editor) Individual Contributor
Hannes Gredler（編集者）個人貢献者
Email: hannes@gredler.at
Jan Medved Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States
Jan Medved Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: jmedved@cisco.com
Stefano Previdi Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy
Stefano Previdi Cisco Systems、Inc. Via Del Serafico、200 Rome 00142 Italy
Email: sprevidi@cisco.com
Adrian Farrel Juniper Networks, Inc.
Adrian Farrel Juniper Networks、Inc.
Email: adrian@olddog.co.uk
Saikat Ray
ビーチの判断
Email: raysaikat@gmail.com