[要約] RFC 7813は、IS-IS(Intermediate System to Intermediate System)パス制御と予約に関する仕様であり、IS-ISプロトコルを使用してネットワークパスの制御と予約を行うための手法を提供します。このRFCの目的は、ネットワークのパフォーマンスと信頼性を向上させるために、IS-ISを使用したパス制御と予約の実装を促進することです。

Internet Engineering Task Force (IETF)                    J. Farkas, Ed.
Request for Comments: 7813                                      Ericsson
Category: Standards Track                                       N. Bragg
ISSN: 2070-1721                                                    Ciena
                                                            P. Unbehagen
                                                                   Avaya
                                                              G. Parsons
                                                                Ericsson
                                                        P. Ashwood-Smith
                                                     Huawei Technologies
                                                               C. Bowers
                                                        Juniper Networks
                                                               June 2016
        

IS-IS Path Control and Reservation

IS-ISパスの制御と予約

Abstract

概要

IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR.

IEEE 802.1Qcaパス制御および予約(PCR)は、IEEE 802.1aq最短パスブリッジング(SPB)によって提供される最短パス機能を超えるために、レイヤー2ネットワークでIS-ISを介した明示的なパス制御を指定します。 IS-IS PCRは、レイヤ2ネットワークドメインで明示的な転送ツリーを確立および制御する機能を提供します。このドキュメントでは、IS-IS PCRのサブTLVを指定します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7813.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7813で入手できます。

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
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   3.  Terminology and Definitions . . . . . . . . . . . . . . . . .   4
   4.  Explicit Trees  . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Explicit ECT Algorithms . . . . . . . . . . . . . . . . . . .   9
   6.  IS-IS PCR Sub-TLVs  . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Topology Sub-TLV  . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Hop Sub-TLV . . . . . . . . . . . . . . . . . . . . . . .  15
     6.3.  Bandwidth Constraint Sub-TLV  . . . . . . . . . . . . . .  19
     6.4.  Bandwidth Assignment Sub-TLV  . . . . . . . . . . . . . .  21
     6.5.  Timestamp Sub-TLV . . . . . . . . . . . . . . . . . . . .  23
   7.  MRT-FRR Application . . . . . . . . . . . . . . . . . . . . .  24
   8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  29
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  29
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  30
     11.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32
        
1. Introduction
1. はじめに

IEEE 802.1Qca Path Control and Reservation (PCR) [IEEE8021Qca] specifies extensions to IS-IS for the control of Explicit Trees (ETs). The PCR extensions are compatible with the Shortest Path Bridging (SPB) extensions to IS-IS specified by [RFC6329] and [IEEE8021aq] (already rolled into [IEEE8021Q]). Furthermore, IS-IS with PCR extensions relies on the SPB architecture and terminology, and some of the IS-IS SPB sub-TLVs are also leveraged. IS-IS PCR builds upon IS-IS and uses IS-IS in a similar way to SPB. IS-IS PCR only addresses point-to-point physical links, although IS-IS also supports shared media LANs.

IEEE 802.1Qcaパス制御および予約(PCR)[IEEE8021Qca]は、明示的ツリー(ET)の制御のためのIS-ISへの拡張を指定します。 PCR拡張機能は、[RFC6329]および[IEEE8021aq]([IEEE8021Q]にすでに組み込まれている)によって指定されたIS-ISへの最短パスブリッジング(SPB)拡張機能と互換性があります。さらに、PCR拡張機能を備えたIS-ISはSPBアーキテクチャと用語に依存しており、IS-IS SPBサブTLVの一部も活用されています。 IS-IS PCRはIS-ISに基づいて構築され、SPBと同様の方法でIS-ISを使用します。 IS-IS PCRはポイントツーポイントの物理リンクのみを扱いますが、IS-ISは共有メディアLANもサポートしています。

This document specifies five IS-IS sub-TLVs for the control of explicit trees by IS-IS PCR in a Layer 2 network as specified by IEEE Std 802.1Qca. In addition to the sub-TLVs specified here, IS-IS PCR relies on the following IS-IS SPB sub-TLVs specified by [RFC6329]:

このドキュメントでは、IEEE Std 802.1Qcaで指定されているレイヤ2ネットワークでIS-IS PCRによって明示的なツリーを制御するための5つのIS-ISサブTLVを指定しています。ここで指定されているサブTLVに加えて、IS-IS PCRは、[RFC6329]で指定されている次のIS-IS SPBサブTLVに依存しています。

o SPB Link Metric sub-TLV

o SPBリンクメトリックサブTLV

o SPB Base VLAN-Identifiers sub-TLV

o SPBベースVLAN識別子サブTLV

o SPB Instance sub-TLV

o SPBインスタンスサブTLV

o SPBV MAC address sub-TLV

o SPBV MACアドレスサブTLV

o SPBM Service Identifier and Unicast Address sub-TLV

o SPBMサービス識別子とユニキャストアドレスサブTLV

These sub-TLVs are used to provide the link metric and the associations among bridges, Media Access Control (MAC) addresses, VLAN IDs (VIDs), and I-SIDs within an IS-IS domain. The use of these SPB sub-TLVs for PCR is specified by IEEE Std 802.1Qca. Note that IS-IS PCR does not require the implementation of the full IS-IS SPB protocol but only the support of these SPB sub-TLVs. A bridge can support both IS-IS SPB and IS-IS PCR at the same time; however, when it supports both, they are implemented by the same IS-IS entity on a per-instance basis.

これらのサブTLVは、IS-ISドメイン内のリンクメトリックと、ブリッジ、メディアアクセスコントロール(MAC)アドレス、VLAN ID(VID)、およびI-SID間の関連付けを提供するために使用されます。 PCRに対するこれらのSPBサブTLVの使用は、IEEE Std 802.1Qcaで指定されています。 IS-IS PCRは、完全なIS-IS SPBプロトコルの実装を必要とせず、これらのSPBサブTLVのサポートのみを必要とすることに注意してください。ブリッジは、IS-IS SPBとIS-IS PCRの両方を同時にサポートできます。ただし、両方をサポートする場合は、同じIS-ISエンティティによってインスタンスごとに実装されます。

The sub-TLVs specified in this document can also be applied for Fast Reroute using Maximally Redundant Trees (MRT-FRR) [RFC7812] in a Layer 2 network. Maximally Redundant Trees (MRTs) are computed as specified in [RFC7811]. If MRT computation is split such that the Generalized Almost Directed Acyclic Graph (GADAG) is computed centrally, then these sub-TLVs can be used to distribute the GADAG, which is identical for each network node throughout a network domain.

このドキュメントで指定されているサブTLVは、レイヤ2ネットワークで最大冗長ツリー(MRT-FRR)[RFC7812]を使用した高速リルートにも適用できます。最大冗長ツリー(MRT)は、[RFC7811]で指定されているように計算されます。 MRT計算が分割されて、一般化されたほぼ有向非巡回グラフ(GADAG)が集中的に計算される場合、これらのサブTLVを使用して、ネットワークドメイン全体の各ネットワークノードで同一であるGADAGを配布できます。

PCR uses IS-IS, the SPB sub-TLVs listed above, and the new sub-TLVs defined in this document. IS-IS PCR has no impact on IETF protocols.

PCRはIS-IS、上記のSPBサブTLV、およびこのドキュメントで定義されている新しいサブTLVを使用します。 IS-IS PCRはIETFプロトコルに影響を与えません。

2. Conventions Used in This Document
2. このドキュメントで使用される規則

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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Terminology and Definitions
3. 用語と定義

This document uses the terminology defined in [RFC7812]. Only the abbreviations are resolved here for the MRT terms; please refer to [RFC7812] for the complete definition.

このドキュメントでは、[RFC7812]で定義されている用語を使用しています。ここでは、MRT用語の省略形のみが解決されます。完全な定義については、[RFC7812]を参照してください。

ADAG: Almost Directed Acyclic Graph [RFC7812]

ADAG:ほとんど有向の非循環グラフ[RFC7812]

B-VID: Backbone VID [IEEE8021Q]

B-VID:バックボーンVID [IEEE8021Q]

Base VID: The VID used to identify a VLAN in management operations. [IEEE8021Q]

ベースVID:管理操作でVLANを識別するために使用されるビデオ。 [IEEE 8021Q]

BLCE: Bridge Local Computation Engine - A computation engine in a bridge that performs path and routing computations. The BLCE implements e.g., SPF, CSPF, or the Maximally Redundant Trees algorithm. [IEEE8021Qca]

BLCE:Bridge Local Computation Engine-パスとルーティングの計算を実行するブリッジの計算エンジン。 BLCEは、SPF、CSPF、または最大冗長ツリーアルゴリズムなどを実装します。 [IEEE8021Qca]

Constrained tree: A tree meeting a certain constraint, e.g., providing minimally available bandwidth. [IEEE8021Qca]

制約付きツリー:特定の制約を満たすツリー。たとえば、最小限の帯域幅を提供します。 [IEEE8021Qca]

CSPF: Constrained Shortest Path First

CSPF:制約付きの最短パスが最初

DAG: Directed Acyclic Graph [RFC7812]

DAG:有向非巡回グラフ[RFC7812]

DEI: Drop Eligible Indicator [IEEE8021Q]

DEI:適格インジケーターの削除[IEEE8021Q]

ECT Algorithm: Equal-Cost Tree algorithm - The algorithm and mechanism that is used for the control of the active topology, i.e., forwarding trees. It can be one of the shortest path algorithms specified by [IEEE8021Q]. It can be also one of the explicit path-control algorithms specified by [IEEE8021Qca]. Each ECT Algorithm has a 32-bit unique ID.

ECTアルゴリズム:等コストツリーアルゴリズム-アクティブトポロジーの制御、つまり転送ツリーに使用されるアルゴリズムとメカニズム。これは、[IEEE8021Q]で指定されている最短パスアルゴリズムの1つです。また、[IEEE8021Qca]で指定されている明示的なパス制御アルゴリズムの1つにもなります。各ECTアルゴリズムには、32ビットの一意のIDがあります。

ET: Explicit Tree - An explicitly defined tree, which is specified by its Edge Bridges and the paths among the Edge Bridges. If only the Edge Bridges are specified but the paths are not, then it is a loose explicit tree. If the paths are also specified, then it is a strict explicit tree. [IEEE8021Qca]

ET:明示的なツリー-明示的に定義されたツリーで、エッジブリッジとエッジブリッジ間のパスによって指定されます。エッジブリッジのみが指定されていてパスが指定されていない場合、それは緩やかな明示的なツリーです。パスも指定されている場合、それは厳密な明示的ツリーです。 [IEEE8021Qca]

ETDB: Explicit Tree Database - A database storing explicit trees. [IEEE8021Qca]

ETDB:明示的なツリーデータベース-明示的なツリーを格納するデータベース。 [IEEE8021Qca]

FDB: Filtering Database [IEEE8021Q]

FDB:データベースのフィルタリング[IEEE8021Q]

GADAG: Generalized ADAG [RFC7812]

Gadag:Generalized Tag [Raffsey]

Hop: A hop is specified by two nodes. A strict hop has no intermediate nodes, whereas a loose hop can have one or more intermediate nodes. IS-IS PCR specifies an explicit tree by an ordered list of hops starting at the root, each successive hop being defined by the next element of the list. [IEEE8021Qca]

ホップ:ホップは2つのノードによって指定されます。ストリクトホップには中間ノードがありませんが、ルーズホップには1つ以上の中間ノードがあります。 IS-IS PCRは、ルートから始まるホップの順序付きリストによって明示的なツリーを指定します。連続する各ホップは、リストの次の要素によって定義されます。 [IEEE8021Qca]

I-SID: Backbone Service Instance Identifier - A 24-bit ID. [IEEE8021Q]

I-SID:バックボーンサー​​ビスインスタンス識別子-24ビットID。 [IEEE8021Q]

LSDB: Link State Database

LSDB:リンク状態データベース

MRT: Maximally Redundant Trees [RFC7812]

MRT:最大冗長ツリー[RFC7812]

MRT-Blue: MRT-Blue is used to describe one of the two MRTs. [RFC7812]

MRT-Blue:MRT-Blueは、2つのMRTの1つを表すために使用されます。 [RFC7812]

MRT-Red: MRT-Red is used to describe one of the two MRTs. [RFC7812]

MRT-Red:MRT-Redは、2つのMRTの1つを表すために使用されます。 [RFC7812]

MRT Root: The common root of the two MRTs: MRT-Blue and MRT-Red.

MRTルート:2つのMRTの共通ルート:MRT-BlueとMRT-Red。

MSRP: Multiple Stream Registration Protocol, standardized as IEEE Std 802.1Qat, already rolled into [IEEE8021Q].

MSRP:IEEE Std 802.1Qatとして標準化された複数ストリーム登録プロトコルはすでに[IEEE8021Q]に組み込まれています。

PCA: Path Control Agent - The agent that is part of the IS-IS domain and thus can perform IS-IS operations on behalf of a PCE, e.g., maintain the LSDB and send LSPs. [IEEE8021Qca]

PCA:パスコントロールエージェント-IS-ISドメインの一部であり、PCEに代わってIS-IS操作を実行できるエージェント。たとえば、LSDBを維持し、LSPを送信します。 [IEEE8021Qca]

PCE: Path Computation Element - An entity that is capable of computing a path through a network based on a representation of the topology of the network (obtained by undefined means external to the PCE). [RFC4655]

PCE:パス計算要素-ネットワークのトポロジーの表現(PCEの外部の未定義の手段によって取得される)に基づいて、ネットワークを通るパスを計算できるエンティティ。 [RFC4655]

PCP: Priority Code Point, which identifies a traffic class. [IEEE8021Q]

PCP:トラフィッククラスを識別する優先コードポイント。 [IEEE8021Q]

PTP: Precision Time Protocol specified by [IEEE1588].

PTP:[IEEE1588]によって指定された高精度時間プロトコル。

SPB: Shortest Path Bridging

SPB:最短経路ブリッジ

SPBM: SPB MAC - The SPB mode where a MAC or its shorthand (SPSourceID: Shortest Path Source ID) is used to identify an SPT. [IEEE8021Q]

SPBM:SPB MAC-MACまたはその短縮形(SPSourceID:最短パスソースID)を使用してSPTを識別するSPBモード。 [IEEE8021Q]

SPBV: SPB VID - The SPB mode where a unique VID is assigned to each SPT Root bridge and is used to identify an SPT. [IEEE8021Q]

SPBV:SPB VID-各SPTルートブリッジに一意のVIDが割り当てられ、SPTを識別するために使用されるSPBモード。 [IEEE8021Q]

SPF: Shortest Path First

SPF:最短パス優先

SPT: Shortest Path Tree [IEEE8021Q]

SPT:最短パスツリー[IEEE8021Q]

SRLG: Shared Risk Link Group - A set of links that share a resource whose failure affects each link. [RFC5307]

SRLG:共有リスクリンクグループ-障害が各リンクに影響するリソースを共有する一連のリンク。 [RFC5307]

TAI: Temps Atomique International - International Atomic Time [IEEE1588]

TAI:国際原子時間-国際原子時間[IEEE1588]

TED: Traffic Engineering Database - A database storing the traffic engineering information propagated by IS-IS. [RFC5305]

TED:トラフィックエンジニアリングデータベース-IS-ISによって伝達されたトラフィックエンジニアリング情報を格納するデータベース。 [RFC5305]

VID: VLAN ID [IEEE8021Q]

VID:VLAN ID [IEEE8021Q]

VLAN: Virtual Local Area Network [IEEE8021Q]

VLAN:仮想ローカルエリアネットワーク[IEEE8021Q]

4. Explicit Trees
4. 明示的なツリー

Explicit trees may be determined in some fashion. For example, an explicit tree may be determined by a Path Computation Element (PCE) [RFC4655]. A PCE is an entity that is capable of computing a topology for forwarding based on a network topology, its corresponding attributes, and potential constraints. If a PCE is used, it MUST explicitly specify an explicit tree as described in Section 6.1. Either a single PCE or multiple PCEs determine explicit trees for a domain. Even if there are multiple PCEs in a domain, each explicit tree MUST only be determined by one PCE, which is referred to as the owner PCE of the tree. PCEs and IS-IS PCR can be used in combination with IS-IS SPB shortest path routing. The remainder of this section, and subsequent sections, are written assuming PCE use.

明示的なツリーは、何らかの方法で決定できます。たとえば、明示的なツリーは、経路計算要素(PCE)[RFC4655]によって決定されます。 PCEは、ネットワークトポロジ、それに対応する属性、および潜在的な制約に基づいて転送用のトポロジを計算できるエンティティです。 PCEを使用する場合は、6.1節で説明するように、明示的なツリーを明示的に指定する必要があります。単一のPCEまたは複数のPCEのいずれかが、ドメインの明示的なツリーを決定します。ドメインに複数のPCEがある場合でも、各明示的なツリーは、ツリーの所有者PCEと呼ばれる1つのPCEによってのみ決定される必要があります。 PCEとIS-IS PCRは、IS-IS SPB最短パスルーティングと組み合わせて使用​​できます。このセクションの以降のセクション、および後続のセクションは、PCEの使用を想定して記述されています。

The PCE interacts with the active topology control protocol, i.e., with IS-IS. The collaboration with IS-IS can be provided by a Path Control Agent (PCA) on behalf of a PCE. Either the PCE or the corresponding PCA is part of the IS-IS domain. If the PCE is not part of the IS-IS domain, then the PCE MUST be associated with a PCA that is part of the IS-IS domain. The PCE or its PCA MUST establish IS-IS adjacency in order to receive all the LSPs transmitted by the bridges in the domain. The PCE, either on its own or via its PCA, can control the establishment of explicit trees in that domain by injecting an LSP conveying an explicit tree and thus instruct IS-IS to set up the explicit tree determined by the PCE. If instructed to do so by a PCE, IS-IS MAY also record and communicate bandwidth assignments, which MUST NOT be applied if reservation protocol (e.g., Multiple Stream Registration Protocol (MSRP)) is used in the domain. Both MSRP and IS-IS MUST NOT be used to make bandwidth assignments in the same domain.

PCEは、アクティブなトポロジ制御プロトコル、つまりIS-ISと対話します。 IS-ISとのコラボレーションは、PCEに代わってパス制御エージェント(PCA)によって提供できます。 PCEまたは対応するPCAはIS-ISドメインの一部です。 PCEがIS-ISドメインの一部でない場合は、PCEをIS-ISドメインの一部であるPCAに関連付ける必要があります。 PCEまたはそのPCAは、ドメイン内のブリッジによって送信されたすべてのLSPを受信するために、IS-IS隣接を確立する必要があります。 PCEは、それ自体で、またはPCAを介して、明示的なツリーを伝達するLSPを注入することにより、そのドメインでの明示的なツリーの確立を制御し、PCEによって決定された明示的なツリーをセットアップするようIS-ISに指示できます。 PCEから指示された場合、IS-ISは帯域幅割り当ても記録および通信できます。ドメインで予約プロトコル(たとえば、複数ストリーム登録プロトコル(MSRP))が使用されている場合は、これを適用してはなりません(MAY)。 MSRPとIS-ISの両方を使用して、同じドメインで帯域幅を割り当てることはできません。

The operation details of the PCE are not specified by this document or by IEEE Std 802.1Qca. If the PCE is part of the IS-IS domain, then the PCE uses IS-IS PDUs to communicate with the IS-IS domain and the PCE has a live IS-IS LSDB (i.e., the PCE implements the PCA functions too). A PCE can instead communicate with the IS-IS domain via a PCA, e.g., to retrieve the LSDB or instruct the creation of an explicit tree. However, the means of communication between the PCE and the PCA is not specified by this document or by IEEE Std 802.1Qca.

PCEの操作の詳細は、このドキュメントまたはIEEE Std 802.1Qcaでは指定されていません。 PCEがIS-ISドメインの一部である場合、PCEはIS-IS PDUを使用してIS-ISドメインと通信し、PCEはライブIS-IS LSDBを持っています(つまり、PCEはPCA機能も実装しています)。代わりに、PCEはPCAを介してIS-ISドメインと通信して、LSDBを取得したり、明示的なツリーの作成を指示したりできます。ただし、PCEとPCA間の通信手段は、このドキュメントまたはIEEE Std 802.1Qcaでは指定されていません。

An Explicit Tree (ET) is an undirected loop-free topology, whose use is under the control of the owner PCE by means of associating VIDs and MAC addresses with it. An ET MUST NOT contain cycles. As it is undirected, an ET contains no assumptions about the direction of any flows that use it; it can be used in either direction as specified by the VIDs and MAC addresses associated with it. It is the responsibility of the PCE to ensure reverse-path congruency and multicast-unicast congruency if that is required.

明示的ツリー(ET)は、無向ループのないトポロジーであり、VIDとMACアドレスを関連付けることにより、所有者のPCEの制御下で使用されます。 ETにサイクルを含めることはできません。それは無向であるため、ETにはそれを使用するフローの方向に関する仮定は含まれていません。関連付けられたVIDとMACアドレスで指定されたどちらの方向でも使用できます。必要に応じて、リバースパスの合同性とマルチキャストユニキャストの合同性を保証するのは、PCEの責任です。

An explicit tree is either strict or loose. A strict explicit tree specifies all bridges and paths it comprises. A loose tree only specifies the bridges as a list of hops that have a special role in the tree, e.g., an Edge Bridge, and no path or path segment is specified between the bridges, which are therefore loose hops even if Edge Bridges are adjacent neighbors. The special role of a hop can be: Edge Bridge, root, leaf, a bridge to be avoided, or a transit hop in case of a tree with a single leaf. The path for a loose hop is determined by the Bridge Local Computation Engine (BLCE) of the bridges. The shortest path is used for a loose hop unless specified otherwise by the descriptor (Section 6.1) of the tree or by the corresponding ECT Algorithm (Section 5).

明示的なツリーは、厳密または緩いです。厳密な明示的ツリーは、それが構成するすべてのブリッジとパスを指定します。ルーズツリーは、エッジブリッジなど、ツリーで特別な役割を持つホップのリストとしてブリッジを指定するだけであり、ブリッジ間にパスまたはパスセグメントが指定されないため、エッジブリッジが隣接している場合でもルーズホップになります。隣人。ホップの特別な役割は、エッジブリッジ、ルート、リーフ、回避するブリッジ、または単一のリーフを持つツリーの場合は中継ホップです。ルーズホップのパスは、ブリッジのBridge Local Computation Engine(BLCE)によって決定されます。ツリーの記述子(セクション6.1)または対応するECTアルゴリズム(セクション5)で特に指定されていない限り、最短パスはルーズホップに使用されます。

A loose explicit tree is constrained if the tree descriptor includes one or more constraints, e.g., the administrative group that the links of the tree have to belong to. The BLCE of the bridges then applies the Constrained Shortest Path First (CSPF) algorithm, which is Shortest Path First (SPF) on the topology that only contains the links meeting the constraint(s).

緩やかな明示的なツリーは、ツリー記述子に1つ以上の制約(ツリーのリンクが属している必要がある管理グループなど)が含まれている場合に制約されます。ブリッジのBLCEは、制約を満たす最短パス優先(CSPF)アルゴリズムを適用します。これは、制約を満たすリンクのみを含むトポロジで最短パス優先(SPF)です。

An explicit tree is specified by a Topology sub-TLV (Section 6.1). The Topology sub-TLV associates one or more VIDs with an explicit tree. The Topology sub-TLV includes two or more Hop sub-TLVs (Section 6.2), and a hop is specified by an IS-IS System ID. A Hop

明示的なツリーは、トポロジサブTLV(セクション6.1)によって指定されます。トポロジサブTLVは、1つ以上のVIDを明示的なツリーに関連付けます。トポロジサブTLVには2つ以上のホップサブTLV(セクション6.2)が含まれ、ホップはIS-ISシステムIDによって指定されます。ホップ

sub-TLV MAY include a delay constraint for a loose hop. A Topology sub-TLV MAY also include further sub-TLVs to constrain loose hops. The bridges involved in an explicit tree store the corresponding Topology sub-TLVs in their Explicit Tree Database (ETDB).

サブTLVには、ルーズホップの遅延制約が含まれる場合があります。トポロジサブTLVには、ルーズホップを抑制するためのサブTLVがさらに含まれる場合があります。明示的ツリーに含まれるブリッジは、対応するトポロジサブTLVを明示的ツリーデータベース(ETDB)に格納します。

Explicit trees are propagated and set up by IS-IS PCR in a domain. The PCE or its PCA assembles the Topology sub-TLVs (Section 6.1), and adds it into an LSP, which is flooded throughout the domain. The Topology sub-TLV is flooded by the same techniques used for the SPB LSPs. The bridges then MUST process the Topology sub-TLV upon reception. If the Topology sub-TLV specifies one or more loose trees, then the path for the loose hops is determined by the BLCE of the bridges. The bridges then install the appropriate FDB entries for frame forwarding along the tree described by the Topology sub-TLV or the trees computed based on the Topology sub-TLV. Dynamic Filtering Entries are maintained by IS-IS for the [VID, MAC address] two-tuples associated with an ET.

明示的なツリーは、ドメイン内でIS-IS PCRによって伝達および設定されます。 PCEまたはそのPCAは、トポロジサブTLV(セクション6.1)をアセンブルし、LSPに追加します。LSPはドメイン全体にフラッディングされます。トポロジサブTLVは、SPB LSPに使用されるのと同じ手法でフラッディングされます。次に、ブリッジは受信時にトポロジサブTLVを処理する必要があります。トポロジサブTLVが1つ以上のルーズツリーを指定している場合、ルーズホップのパスはブリッジのBLCEによって決定されます。次に、ブリッジは、トポロジサブTLVによって記述されたツリーまたはトポロジサブTLVに基づいて計算されたツリーに沿ったフレーム転送に適切なFDBエントリをインストールします。ダイナミックフィルタリングエントリは、ETに関連付けられた[VID、MACアドレス] 2タプルのIS-ISによって維持されます。

Due to the LSP aging of IS-IS, the Topology sub-TLVs (Section 6.1) have to be refreshed similar to other IS-IS TLVs in order to keep the integrity of the LSDB. The corresponding Dynamic Filtering Entries are also refreshed in the FDB when a Topology sub-TLV is refreshed. Refreshing Topology sub-TLVs is the task of the entity being part of the IS-IS domain, i.e., either the PCE or the PCA.

IS-ISのLSPエージングにより、LSDBの整合性を維持するために、トポロジサブTLV(セクション6.1)を他のIS-IS TLVと同様に更新する必要があります。トポロジサブTLVが更新されると、対応する動的フィルタリングエントリもFDBで更新されます。トポロジサブTLVの更新は、IS-ISドメインの一部であるエンティティ、つまりPCEまたはPCAのタスクです。

The owner PCE can withdraw an explicit tree by sending an updated LSP that does not include the Topology sub-TLV (Section 6.1). If a Topology sub-TLV is removed from an LSP (or has been changed) so that (previous) Topology sub-TLV is no longer present (or has been changed) in the LSDB, then that (previous) Topology sub-TLV is implicitly withdrawn. IS-IS PCR then removes (or updates) the explicit tree.

所有者PCEは、トポロジサブTLVを含まない更新されたLSPを送信することにより、明示的なツリーを撤回できます(セクション6.1)。トポロジサブ-TLVがLSPから削除された(または変更された)ため、LSDBに(以前の)トポロジサブ-TLVが存在しない(または変更された)場合、その(以前の)トポロジサブ-TLVは暗黙的に撤回されました。次に、IS-IS PCRは明示的なツリーを削除(または更新)します。

There is no precedence order between explicit trees. Precedence order among bandwidth assignments recorded by IS-IS PCR is specified in Section 6.4.

明示的なツリー間に優先順位はありません。 IS-IS PCRによって記録された帯域幅割り当て間の優先順位は、セクション6.4で指定されています。

If it is not possible to install an explicit tree, e.g., constraint(s) cannot be met or the Topology sub-TLV is ill-formed, then no tree is installed, but a management report is generated.

明示的なツリーをインストールできない場合、たとえば、制約が満たされなかったり、トポロジサブTLVの形式が正しくない場合、ツリーはインストールされませんが、管理レポートが生成されます。

The bridges MAY support the following IS-IS features for the computation of explicit trees. The Extended IS Reachability TLV (type 22) specified in [RFC5305] provides the following link attribute IS-IS sub-TLVs:

ブリッジは、明示的なツリーの計算のために次のIS-IS機能をサポートする場合があります。 [RFC5305]で指定されている拡張IS到達可能性TLV(タイプ22)は、次のリンク属性IS-ISサブTLVを提供します。

o Administrative Group (color) (sub-TLV type 3), o Maximum Link Bandwidth (sub-TLV type 9),

o管理グループ(色)(サブTLVタイプ3)、o最大リンク帯域幅(サブTLVタイプ9)、

o Maximum Reservable Link Bandwidth (sub-TLV type 10),

o 最大予約可能リンク帯域幅(サブTLVタイプ10)、

o Unreserved Bandwidth (sub-TLV type 11),

o 予約されていない帯域幅(サブTLVタイプ11)、

o TE Default Metric (sub-TLV type 18).

o TEデフォルトメトリック(サブTLVタイプ18)。

When the Unreserved Bandwidth sub-TLV is used in a Layer 2 bridge network, the priority value encoded in the sub-TLV provides the PCP, i.e., identifies a traffic class (not a setup priority level).

予約されていない帯域幅のサブTLVがレイヤー2ブリッジネットワークで使用される場合、サブTLVでエンコードされた優先度値はPCPを提供します。つまり、(設定優先度レベルではなく)トラフィッククラスを識別します。

Further attributes are provided by the IS-IS TE Metric Extension link attribute sub-TLVs specified in [RFC7810]:

[RFC7810]で指定されているIS-IS TEメトリック拡張リンク属性サブTLVによって、さらに属性が提供されます。

o Unidirectional Link Delay (sub-TLV type 33),

o 単方向リンク遅延(サブTLVタイプ33)、

o Min/Max Unidirectional Link Delay (sub-TLV type 34),

o 最小/最大単方向リンク遅延(サブTLVタイプ34)、

o Unidirectional Delay Variation (sub-TLV type 35),

o 単方向遅延変動(サブTLVタイプ35)、

o Unidirectional Link Loss (sub-TLV type 36),

o 単方向リンク損失(サブTLVタイプ36)、

o Unidirectional Residual Bandwidth (sub-TLV type 37),

o 単方向残余帯域幅(サブTLVタイプ37)、

o Unidirectional Available Bandwidth (sub-TLV type 38),

o 単一方向の利用可能な帯域幅(サブTLVタイプ38)、

o Unidirectional Utilized Bandwidth (sub-TLV type 39).

o 単一方向利用帯域幅(サブTLVタイプ39)。

The Shared Risk Link Group (SRLG) information provided by the SRLG TLV (type 138) [RFC5307] MAY also be used. In order to indicate that the interface is unnumbered in this case, the corresponding flag takes value 0. The Link Local Identifier is an Extended Local Circuit Identifier and the Link Remote Identifier is a Neighbor Extended Local Circuit ID.

SRLG TLV(タイプ138)[RFC5307]によって提供される共有リスクリンクグループ(SRLG)情報も使用できます。この場合、インターフェイスが番号付けされていないことを示すために、対応するフラグは値0をとります。リンクローカル識別子は拡張ローカル回線識別子であり、リンクリモート識別子はネイバー拡張ローカル回線IDです。

5. Explicit ECT Algorithms
5. 明示的なECTアルゴリズム

The exact IS-IS control mode of operation MUST be selected for a VLAN by associating its Base VID with the appropriate ECT Algorithm in the SPB Base VLAN-Identifiers sub-TLV [RFC6329], in addition to allocating the Base VID to IS-IS control. There are five distinct ECT Algorithms for the five explicit path control modes. The operation details of the explicit ECT Algorithms and their configuration is specified by IEEE Std 802.1Qca; a high-level overview is given here. An ECT Algorithm value consists of the IEEE 802.1 OUI (Organizationally Unique Identifier) value 00-80-C2 concatenated with an index [RFC6329].

IS-ISにベースVIDを割り当てることに加えて、ベースVIDをSPBベースVLAN-識別子サブTLV [RFC6329]で適切なECTアルゴリズムに関連付けることにより、正確なIS-IS制御モードの操作をVLANに対して選択する必要があります。コントロール。 5つの明示的なパス制御モードには、5つの異なるECTアルゴリズムがあります。明示的なECTアルゴリズムとその構成の操作の詳細は、IEEE Std 802.1Qcaで指定されています。ここでは、概要を説明します。 ECTアルゴリズムの値は、IEEE 802.1 OUI(Organizationally Unique Identifier)の値00-80-C2とインデックス[RFC6329]を連結して構成されます。

The Strict Tree (ST) ECT Algorithm MUST be used for a strict explicit tree. A strict ET is static, as no other entity can update it but the owner PCE. In case of a topology change, it is the task of the owner PCE to detect the topology change, e.g., based on the changes in the LSDB and to update the strict trees if needed. That is, the owner PCE computes the new tree, assembles its descriptor (Section 6.1), and then instructs IS-IS PCR to install it. The value for the ST ECT Algorithm is 00-80-C2-17.

厳密なツリー(ST)ECTアルゴリズムは、厳密な明示的なツリーに使用する必要があります。厳密なETは静的であり、所有者のPCE以外のエンティティは更新できません。トポロジ変更の場合、所有者PCEは、たとえばLSDBの変更に基づいてトポロジ変更を検出し、必要に応じて厳密なツリーを更新する必要があります。つまり、所有者PCEは新しいツリーを計算し、その記述子を組み立て(セクション6.1)、IS-IS PCRにインストールを指示します。 ST ECTアルゴリズムの値は00-80-C2-17です。

The Loose Tree (LT) ECT Algorithm MAY also be supported. It is used for a single loose explicit tree. The path for loose hops is determined by the BLCE of the bridges; therefore, the Topology sub-TLV (Section 6.1) specifying the tree MUST indicate which hop is the root of the tree. The loose hops are maintained by IS-IS, i.e., restored upon a topology change if a loop-free path is available. If the tree computed by the BLCE visits the same bridge twice (implying that a loop or hairpin has been created), then that loop or hairpin MUST be pruned from the tree even if it contains a hop specified by the Topology sub-TLV. It is a constraint if a bridge is not to be included, which can be specified by the Exclude flag of a Hop sub-TLV (Section 6.2) conveyed by the Topology sub-TLV specifying the tree. The range of values for the LT ECT Algorithms is 00-80-C2-21...00-80-C2-30.

ルーズツリー(LT)ECTアルゴリズムもサポートされる場合があります。単一のルーズエクスプリシットツリーに使用されます。ルーズホップのパスは、ブリッジのBLCEによって決定されます。したがって、ツリーを指定するトポロジサブTLV(セクション6.1)は、ツリーのルートであるホップを示す必要があります。ルーズホップはIS-ISによって維持されます。つまり、ループのないパスが利用可能な場合はトポロジーの変更時に復元されます。 BLCEによって計算されたツリーが同じブリッジを2回訪問する場合(ループまたはヘアピンが作成されたことを意味します)、そのループまたはヘアピンは、トポロジサブTLVで指定されたホップが含まれている場合でも、ツリーからプルーニングする必要があります。これは、ブリッジを含めない場合の制約であり、ツリーを指定するトポロジーサブTLVによって伝達されるホップサブTLV(セクション6.2)の除外フラグで指定できます。 LT ECTアルゴリズムの値の範囲は00-80-C2-21 ... 00-80-C2-30です。

The Loose Tree Set (LTS) ECT Algorithm MAY also be supported. It is used if connectivity among the Edge Bridges specified by the Topology sub-TLV (Section 6.1) is to be provided by a set of loose trees such that one tree is rooted at each Edge Bridge. The BLCE of the bridges compute the loose trees, which are maintained by IS-IS, i.e., restored upon a topology change. One constraint can be to avoid some bridges in these trees, which can be specified by the Exclude flag (item c.6. in Section 6.2). Further constraints can be specified by the Topology sub-TLV. The range of values for the LT ECT Algorithms is 00-80-C2-31...00-80-C2-40.

ルーズツリーセット(LTS)ECTアルゴリズムもサポートされる場合があります。トポロジサブTLV(セクション6.1)で指定されたエッジブリッジ間の接続が、1つのツリーが各エッジブリッジをルートとするルーズツリーのセットによって提供される場合に使用されます。ブリッジのBLCEはルーズツリーを計算します。ルーズツリーはIS-ISによって維持されます。つまり、トポロジの変更時に復元されます。 1つの制約は、これらのツリー内のいくつかのブリッジを回避することです。これは、除外フラグ(セクション6.2の項目c.6)で指定できます。トポロジサブTLVでさらに制約を指定できます。 LT ECTアルゴリズムの値の範囲は00-80-C2-31 ... 00-80-C2-40です。

The LT and LTS ECT Algorithms use the shortest paths after pruning the topology according to the constraint(s), if any. The shortest path tie-breaking specified by Section 12 of [RFC6329] is applied (see also subclauses 28.5 - 28.8 of [IEEE8021aq]), that's why range of values are associated with the LT and LTS ECT Algorithms. In case of the LT ECT Algorithm, the indexes are 0x21...0x30, and ECT-MASK{index-0x20} is applied to retrieve the ECT-MASK of Section 12 of [RFC6329]. In case of the LTS ECT Algorithm, the indexes are 0x31...0x40, and ECT-MASK{index-0x30} is applied to retrieve the ECT-MASK for shortest path tie-breaking.

LTおよびLTS ECTアルゴリズムは、制約に従ってトポロジーをプルーニングした後、もしあれば、最短パスを使用します。 [RFC6329]のセクション12で指定された最短パスタイブレーキングが適用されます([IEEE8021aq]の28.5〜28.8節も参照)。これが、値の範囲がLTおよびLTS ECTアルゴリズムに関連付けられている理由です。 LT ECTアルゴリズムの場合、インデックスは0x21 ... 0x30であり、ECT-MASK {index-0x20}を適用して、[RFC6329]のセクション12のECT-MASKを取得します。 LTS ECTアルゴリズムの場合、インデックスは0x31 ... 0x40であり、ECT-MASK {index-0x30}が適用されて、ECT-MASKを取得して最短パスのタイブレイクを実現します。

The MRT ECT Algorithm MAY also be supported. It is used for the establishment and maintenance of MRTs in a distributed fashion. The MRT Lowpoint algorithm specified by [RFC7811] MUST be used for the computation of MRTs. The MRT Lowpoint algorithm first computes the GADAG and then produces two MRTs for each MRT Root: MRT-Blue and MRT-Red. If the level of redundancy provided by each bridge being an MRT Root is not required, then the MRT Roots can be specified by a Topology sub-TLV (Section 6.1). Both the GADAG and the MRT computation steps are performed distributed, i.e., by each bridge. The value for the MRT ECT Algorithm is 00-80-C2-18.

MRT ECTアルゴリズムもサポートされる場合があります。 MRTの確立と保守に分散して使用されます。 [RFC7811]で指定されているMRTローポイントアルゴリズムは、MRTの計算に使用する必要があります。 MRTローポイントアルゴリズムは、最初にGADAGを計算し、次に各MRTルートに対して2つのMRT(MRT-BlueとMRT-Red)を生成します。 MRTルートである各ブリッジによって提供される冗長性のレベルが必要ない場合、MRTルートはトポロジサブTLV(セクション6.1)で指定できます。 GADAGとMRTの計算ステップは、分散されて、つまり各ブリッジによって実行されます。 MRT ECTアルゴリズムの値は00-80-C2-18です。

The MRT GADAG (MRTG) ECT Algorithm MAY also be supported. It splits the computation into two. As the GADAG is identical for each MRT within a domain, it is computed by a single entity, which is the GADAG Computer. The GADAG is then described in a Topology sub-TLV (Section 6.1), which is flooded in the domain. The bridges then compute the MRTs for the MRT Roots based on the GADAG received. Section 7 provides more details on the description of the GADAG. The value for the MRTG ECT Algorithm is 00-80-C2-19.

MRT GADAG(MRTG)ECTアルゴリズムもサポートされる場合があります。計算を2つに分割します。 GADAGはドメイン内の各MRTで同一であるため、GADAGコンピューターという単一のエンティティーによって計算されます。次に、GADAGは、トポロジーサブTLV(セクション6.1)で記述され、ドメインでフラッディングされます。次に、ブリッジは受信したGADAGに基づいてMRTルートのMRTを計算します。セクション7では、GADAGの説明について詳しく説明します。 MRTG ECTアルゴリズムの値は00-80-C2-19です。

MRTs are loose trees as bridges are involved in their computation and restoration. Thus, both the MRT and the MRTG ECT Algorithms provide a set of loose trees: two MRTs for each MRT Root.

橋はそれらの計算と復元に関与しているため、MRTはルーズツリーです。したがって、MRTアルゴリズムとMRTG ECTアルゴリズムの両方で、ルーズツリーのセット(各MRTルートに2つのMRT)が提供されます。

The SPB Link Metric sub-TLV [RFC6329] specifies the metric of each link for IS-IS PCR if the LT, the LTS, the MRT, or the MRTG ECT Algorithm is used. If the SPB Link Metric values advertised by different ends of an adjacency are different, then the maximum value MUST be used.

SPBリンクメトリックサブTLV [RFC6329]は、LT、LTS、MRT、またはMRTG ECTアルゴリズムが使用される場合、IS-IS PCRの各リンクのメトリックを指定します。隣接の異なる端によってアドバタイズされるSPBリンクメトリック値が異なる場合、最大値を使用する必要があります。

6. IS-IS PCR Sub-TLVs
6. IS-IS PCRサブTLV

The following sub-TLVs are specified for IS-IS PCR. The Topology sub-TLV MUST be carried in an MT-Capability TLV, the rest of the sub-TLVs are conveyed by the Topology sub-TLV.

IS-IS PCRには、次のサブTLVが指定されています。トポロジサブTLVはMT機能TLVで伝送する必要があり、残りのサブTLVはトポロジサブTLVによって伝達されます。

6.1. Topology Sub-TLV
6.1. トポロジサブTLV

An explicit tree MUST be described by the variable-length Topology sub-TLV. A Generalized Almost Directed Acyclic Graph (GADAG) MAY be described by a Topology sub-TLV as explained in Section 7 in detail. The Topology sub-TLV MUST be carried in an MT-Capability TLV (type 144) [RFC6329] in a Link State PDU. A Topology sub-TLV specifying an explicit tree conveys one or more Base VIDs, two or more Hop sub-TLVs (Section 6.2). A Topology sub-TLV describing a loose tree MAY also convey further sub-TLVs to specify constraints. Figure 1 shows the format of the Topology sub-TLV.

明示的なツリーは、可変長トポロジサブTLVによって記述されなければなりません(MUST)。セクション7で詳細に説明されているように、一般化されたほぼ有向非循環グラフ(GADAG)は、トポロジサブTLVによって記述される場合があります。トポロジサブTLVは、リンク状態PDUのMT機能TLV(タイプ144)[RFC6329]で伝送する必要があります。明示的なツリーを指定するトポロジサブTLVは、1つ以上のベースVID、2つ以上のホップサブTLVを伝達します(セクション6.2)。ルーズツリーを記述するトポロジサブTLVは、制約を指定するためのサブTLVをさらに伝達する場合があります。図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      |                   (1 byte)
     +-+-+-+-+-+-+-+-+
     |    Length     |                   (1 byte)
     +-+-+-+-+-+-+-+-+
     | Num Base VIDs |                   (1 byte)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Res  |  Base VID 1 (12 bits) |   (2 bytes if present)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            .................
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Res  |  Base VID n (12 bits) |   (2 bytes if present)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        sub-TLV 1  (variable)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              .................
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        sub-TLV m  (variable)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 1: Topology Sub-TLV

図1:トポロジサブTLV

The parameters of explicit trees are encoded by the Topology sub-TLV as follows:

明示的なツリーのパラメータは、トポロジサブTLVによって次のようにエンコードされます。

a. Type (8 bits): The type of the sub-TLV, its value is 21.

a. タイプ(8ビット):サブTLVのタイプ。値は21です。

b. Length (8 bits): The total number of bytes contained in the Value field.

b. 長さ(8ビット):「値」フィールドに含まれるバイトの総数。

c. Number of Base VIDs (8 bits): The number of Base VIDs carried in the Topology sub-TLV. Its minimum value is 1 if the Topology sub-TLV specifies one or more explicit trees. Its value can be 0 if the Topology sub-TLV specifies a GADAG.

c. ベースVIDの数(8ビット):トポロジサブTLVで伝送されるベースVIDの数。トポロジサブTLVが1つ以上の明示的なツリーを指定している場合、その最小値は1です。トポロジサブTLVがGADAGを指定している場合、その値は0になります。

d. Reserved (Res) (4 bits): The reserved bits MUST be set to 0 on transmission and the value MUST be ignored on reception.

d. 予約済み(Res)(4ビット):予約済みビットは送信時に0に設定する必要があり、値は受信時に無視する必要があります。

e. Base VID (12 bits): The Base VID parameter provides the Base VID of the VLAN that is associated with the explicit tree. Multiple Base VIDs can be associated with the same explicit tree. In addition to the Base VID, some of the explicit ECT Algorithms (Section 5) require further VIDs that are associated with the VLAN via the SPB Instance sub-TLV [RFC6329]. A Topology sub-TLV specifying a GADAG can have zero Base VID parameters. In this case, the given GADAG MUST be applied for each VLAN associated with the MRTG ECT Algorithm (Section 5).

e。ベースVID(12ビット):ベースVIDパラメーターは、明示的なツリーに関連付けられているVLANのベースVIDを提供します。複数のベースVIDを同じ明示的なツリーに関連付けることができます。ベースVIDに加えて、いくつかの明示的なECTアルゴリズム(セクション5)には、SPBインスタンスサブTLV [RFC6329]を介してVLANに関連付けられている追加のVIDが必要です。 GADAGを指定するトポロジサブTLVは、ゼロのベースVIDパラメータを持つことができます。この場合、MRTG ECTアルゴリズム(セクション5)に関連付けられた各VLANに、指定されたGADAGを適用する必要があります。

f. sub-TLVs: The rest conveys further sub-TLVs that specify the hops of the topology and can also specify constraints as described in the following.

f. サブTLV:残りは、トポロジのホップを指定するサブTLVをさらに伝達し、以下で説明するように制約を指定することもできます。

A topology is specified by a list of Hop sub-TLVs (Section 6.2), and a hop is specified by an IS-IS System ID. An ill-formed Topology sub-TLV (e.g., specifying an invalid or inconsistent tree) is ignored; no tree is installed, but a management report is generated.

トポロジーはホップサブTLV(セクション6.2)のリストで指定され、ホップはIS-ISシステムIDで指定されます。不正な形式のトポロジサブTLV(たとえば、無効または一貫性のないツリーの指定)は無視されます。ツリーはインストールされていませんが、管理レポートが生成されます。

The Topology sub-TLV specifies a strict tree by decomposing the tree to branches. Each branch is a point-to-point path specified by an ordered list of hops where the end of each branch is a leaf. Each element of a branch is the direct link between adjacent neighbor bridges whose Hop sub-TLV is next to each other in the Topology sub-TLV. The first hop of the Topology sub-TLV is the root; hence, the first branch originates from the root. The rest of the branches fork from another branch. The first hop of a branch is a bridge that is already part of a former branch, and the last hop is a leaf bridge. Therefore, the hop after a leaf hop is the beginning of a new branch, if any. A hop of a branch is created if and only if the bridge specified for that hop is directly connected to the preceding bridge of the same branch. The first branch MUST begin with the root; after that, the order of the branches does not matter within the Topology sub-TLV. Figure 2 shows an example strict tree and its description.

トポロジサブTLVは、ツリーをブランチに分解することにより、厳密なツリーを指定します。各ブランチは、ホップの順序付きリストで指定されたポイントツーポイントパスであり、各ブランチの終わりはリーフです。ブランチの各要素は、トポロジーサブ-TLVでホップサブ-TLVが互いに隣接している隣接する隣接ブリッジ間の直接リンクです。トポロジサブTLVの最初のホップはルートです。したがって、最初のブランチはルートから始まります。残りのブランチは別のブランチから分岐します。ブランチの最初のホップは、以前のブランチの一部であるブリッジであり、最後のホップはリーフブリッジです。したがって、リーフホップの後のホップは、もしあれば、新しいブランチの始まりです。ブランチのホップは、そのホップに指定されたブリッジが同じブランチの先行するブリッジに直接接続されている場合にのみ作成されます。最初のブランチはルートで始まる必要があります。その後、トポロジサブTLVではブランチの順序は関係ありません。図2は、厳格なツリーの例とその説明を示しています。

                                           +-----------+
                                           |     A     |
                                           +-----------+
                                           |     I     |
                                           +-----------+
                                           |     H     |
                  [B]---[A]---[I]          +-----------+
                   |           |           |     G     |
                   |           |           +-----------+
                   |           |           |     E     |
                  [C]---[F]   [H]          +-----------+
                   |           |           |     A     |
                   |           |           +-----------+
                   |           |           |     B     |
                  [D]   [E]---[G]          +-----------+
                                           |     C     |
                                           +-----------+
                                           |     D     |
                                           +-----------+
                                           |     C     |
                                           +-----------+
                                           |     F     |
                                           +-----------+
        
        Figure 2: A Strict Tree and Its Description; Root = Node A
        

The Topology sub-TLV of a loose tree does not provide any path or path segment other than the hops that are to participate. The root MUST be the first hop. The leaves of a single loose tree MUST also be specified. Hop sub-TLVs can be included in a Topology sub-TLV to specify bridges that have to be avoided. If the Topology sub-TLV only specifies a single leaf, then one or more transit hops can be specified by the Topology sub-TLV to direct the path along a sequence of bridges, specified by the order of hops. If bridges whose respective Hop sub-TLVs are adjacent to each other in the Topology sub-TLV are not topology neighbors, then it is a loose hop. If a Topology sub-TLV conveys one or more loose hops, then that sub-TLV defines a loose explicit tree and each hop is considered to be a loose hop. The path of a loose hop MUST be pruned from the tree if the path would create a loop or hairpin.

ルーズツリーのトポロジサブTLVは、参加するホップ以外のパスまたはパスセグメントを提供しません。ルートは最初のホップでなければなりません。単一のルーズツリーの葉も指定する必要があります。ホップサブTLVをトポロジサブTLVに含めて、回避する必要があるブリッジを指定できます。トポロジサブTLVが単一のリーフのみを指定する場合、トポロジサブTLVは1つ以上のトランジットホップを指定して、ホップの順序で指定された一連のブリッジに沿ってパスを誘導できます。それぞれのホップサブTLVがトポロジサブTLVで互いに隣接しているブリッジがトポロジネイバーでない場合、それはルーズホップです。トポロジサブTLVが1つ以上のルーズホップを伝達する場合、そのサブTLVはルーズな明示的ツリーを定義し、各ホップはルーズホップと見なされます。パスがループまたはヘアピンを作成する場合は、ルーズホップのパスをツリーから削除する必要があります。

If the Base VIDs of the Topology sub-TLV are associated with the LTS ECT Algorithm or the MRT ECT Algorithm, then the Hop sub-TLVs conveyed by the Topology sub-TLV belong to Edge Bridges or bridges to be excluded. The BLCEs compute the loose trees, e.g., MRTs, such that they span the Edge Bridges and are rooted at an Edge Bridge.

トポロジサブTLVのベースVIDがLTS ECTアルゴリズムまたはMRT ECTアルゴリズムに関連付けられている場合、トポロジサブTLVによって伝達されるホップサブTLVは、除外されるエッジブリッジまたはブリッジに属します。 BLCEは、MRTなどのルーズツリーを計算して、エッジブリッジにまたがり、エッジブリッジをルートとします。

The Topology sub-TLV specifies a GADAG if the Base VIDs conveyed by the Topology sub-TLV are associated with the MRTG ECT Algorithm. Section 7 provides the details on the description of a GADAG by a Topology sub-TLV.

トポロジサブTLVは、トポロジサブTLVによって伝達されるベースVIDがMRTG ECTアルゴリズムに関連付けられている場合にGADAGを指定します。セクション7では、トポロジサブTLVによるGADAGの説明の詳細について説明します。

Each Edge Bridge of an explicit tree MUST always be specified in the Topology sub-TLV by the inclusion of the Hop sub-TLVs corresponding to the Edge Bridges. The Edge Bridges of a tree are identified by setting the Edge Bridge flag (item c.3. in Section 6.2) in the appropriate Hop sub-TLVs.

明示的なツリーの各エッジブリッジは、エッジブリッジに対応するホップサブTLVを含めることにより、常にトポロジサブTLVで指定する必要があります。ツリーのエッジブリッジは、適切なホップサブTLVにエッジブリッジフラグ(セクション6.2の項目c.3)を設定することによって識別されます。

If the explicit tree is loose, then the Topology sub-TLV MAY convey further sub-TLVs to specify constraints, e.g., an Administrative Group sub-TLV [RFC5305] or a Bandwidth Constraint (Section 6.3). If it is not possible to meet the constraint(s) specified by the Topology sub-TLV, then no tree is installed but a management report is generated.

明示的なツリーが緩い場合、トポロジサブTLVはさらにサブTLVを伝達して、管理グループサブTLV [RFC5305]や帯域幅制約などの制約を指定できます(セクション6.3)。トポロジサブTLVで指定された制約を満たすことができない場合、ツリーはインストールされませんが、管理レポートが生成されます。

IS-IS PCR MAY be used for recording bandwidth assignment. In that case, the Topology sub-TLV conveys Bandwidth Assignment sub-TLV (Section 6.4), and it MAY also convey Timestamp sub-TLV (Section 6.5). If assignment of the bandwidth indicated by the Bandwidth Assignment sub-TLV of the Topology sub-TLV would result in overbooking any link of the explicit tree, then bandwidth assignment MUST NOT be performed and a management report is generated. If the Topology sub-TLV specifies a new valid explicit tree, then the tree is installed without bandwidth assignment.

IS-IS PCRは、帯域幅割り当ての記録に使用できます。その場合、トポロジーサブTLVは帯域幅割り当てサブTLV(セクション6.4)を伝達し、タイムスタンプサブTLV(セクション6.5)も伝達してもよい(MAY)。トポロジーサブ-TLVの帯域幅割り当てサブ-TLVによって示される帯域幅の割り当てが明示的なツリーのリンクをオーバーブッキングする場合、帯域幅割り当てを実行してはならず(MUST NOT)、管理レポートが生成されます。トポロジサブTLVが新しい有効な明示的ツリーを指定する場合、ツリーは帯域幅割り当てなしでインストールされます。

6.2. Hop Sub-TLV
6.2. ホップサブTLV

The Hop sub-TLV MUST be used to specify a hop of a topology. Each Hop sub-TLV conveys an IS-IS System ID, which specifies a hop. A Hop sub-TLV is conveyed by a Topology sub-TLV (Section 6.1). A strict explicit tree is decomposed to branches where each branch is a point-to-point path specified by an ordered list of Hop sub-TLVs as specified in Section 6.1. A hop of a branch is created if and only if the bridge specified for that hop is directly connected to the preceding bridge in the path. That is, a point-to-point LAN is identified by the two bridges it interconnects; and the LAN is part of the strict tree if and only if the Hop sub-TLVs of the two bridges are next to each other in the Topology sub-TLV. A Hop sub-TLV can convey a Circuit ID in order to distinguish multiple links between adjacent neighbor bridges. A Hop sub-TLV also specifies the role of a bridge, e.g., if it is the root or an Edge Bridge. The Topology sub-TLV of a loose tree only comprises the Hop sub-TLV of the bridges that have a special role in the tree. The Hop sub-TLV MAY also specify a delay budget for a loose hop.

トポロジのホップを指定するには、ホップサブTLVを使用する必要があります。各ホップサブTLVは、ホップを指定するIS-ISシステムIDを伝達します。ホップサブTLVは、トポロジサブTLV(セクション6.1)によって伝達されます。厳密な明示的ツリーはブランチに分解され、各ブランチは、セクション6.1で指定されたホップサブTLVの順序付きリストで指定されたポイントツーポイントパスです。ブランチのホップは、そのホップに指定されたブリッジがパス内の先行するブリッジに直接接続されている場合にのみ作成されます。つまり、ポイントツーポイントLANは、相互接続する2つのブリッジによって識別されます。また、2つのブリッジのホップサブTLVがトポロジサブTLVで互いに隣接している場合にのみ、LANは厳密なツリーの一部です。ホップサブTLVは、隣接する隣接ブリッジ間の複数のリンクを区別するために、回線IDを伝達できます。ホップサブTLVは、ブリッジの役割も指定します(例:ルートブリッジまたはエッジブリッジの場合)。ルーズツリーのトポロジサブTLVは、ツリーで特別な役割を持つブリッジのホップサブTLVのみで構成されます。ホップサブTLVは、ルーズホップの遅延バジェットも指定してもよい(MAY)。

By default, the Edge Bridges both transmit and receive with respect to each VID associated with an explicit tree, except for an LTS (Section 5) associated with a learning VLAN, which uses a unidirectional VID per bridge. The Hop sub-TLV allows different configuration by means of the Transmit (T) and Receive (R) flags conveyed in the sub-TLV. The VID and its T/R flags are only present in the Hop sub-TLV if the behavior of the Edge Bridges differs from the default.

デフォルトでは、エッジブリッジは、明示的なツリーに関連付けられた各VIDに関して送信と受信の両方を行います。ただし、ブリッジごとに単方向VIDを使用する学習VLANに関連付けられたLTS(セクション5)は除きます。ホップサブTLVでは、サブTLVで伝達される送信(T)フラグと受信(R)フラグを使用して、さまざまな構成が可能です。 VIDとそのT / Rフラグは、エッジブリッジの動作がデフォルトと異なる場合にのみ、ホップサブTLVに存在します。

Figure 3 shows the format of the variable length Hop sub-TLV, which MUST be conveyed by a Topology sub-TLV (Section 6.1).

図3は、可変長ホップサブTLVのフォーマットを示しています。これは、トポロジサブTLV(セクション6.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
     +-+-+-+-+-+-+-+-+
     |     Type      |                       (1 byte)
     +-+-+-+-+-+-+-+-+
     |    Length     |                       (1 byte)
     +-+-+-+-+-+-+-+-+
     |C|V|B|R|L|E|Res|                       (1 byte)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            System ID                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          System ID            |       (6 bytes)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Extended Local Circuit ID  (4 bytes if present)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Num of VIDs  |                       (1 byte if present)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|R|Res|     VID 1   (12 bits) |       (2 bytes if present)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            .................
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|R|Res|     VID n   (12 bits) |       (2 bytes if present)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Delay Constraint                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Delay Constraint       |       (6 bytes if present)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 3: Hop Sub-TLV

図3:ホップサブTLV

The parameters of a hop are encoded as follows:

ホップのパラメーターは次のようにエンコードされます。

a. Type (8 bits): The type of the sub-TLV, its value is 22.

a. タイプ(8ビット):サブTLVのタイプ。値は22です。

b. Length (8 bits): The total number of bytes contained in the Value field.

b. 長さ(8ビット):「値」フィールドに含まれるバイトの総数。

c. Hop Flags (8 bits): The Hop sub-TLV conveys six one-bit flags. The Circuit and the VID flags influence the length of the Hop sub-TLV. Two bits are reserved for future use, transmitted as 0 and ignored on receipt.

c. ホップフラグ(8ビット):ホップサブTLVは6つの1ビットフラグを伝達します。 CircuitフラグとVIDフラグは、HopサブTLVの長さに影響します。 2ビットは将来の使用のために予約されており、0として送信され、受信時に無視されます。

1. Circuit (C) flag (1 bit): The Circuit flag is a one-bit flag to indicate whether or not the Extended Local Circuit ID parameter is present. If the flag is set, then an Extended Local Circuit ID is also included in the Hop sub-TLV.

1. 回路(C)フラグ(1ビット):回路フラグは、拡張ローカル回路IDパラメーターが存在するかどうかを示す1ビットのフラグです。フラグが設定されている場合、拡張ローカル回線IDもホップサブTLVに含まれます。

2. VID (V) flag (1 bit): The VID flag is a one-bit flag to indicate whether or not one or more VIDs are conveyed by the Hop sub-TLV. If the flag is set, then the Number of VIDs parameter is present and indicates how many VIDs are conveyed by the Hop sub-TLV. If the VID flag is reset, then neither the Number of VIDs parameter nor VIDs are present in the Hop sub-TLV.

2. VID(V)フラグ(1ビット):VIDフラグは、1つ以上のVIDがホップサブTLVによって伝達されるかどうかを示す1ビットのフラグです。フラグが設定されている場合、Number of VIDsパラメーターが存在し、HopサブTLVによって伝達されるVIDの数を示します。 VIDフラグがリセットされた場合、VIDの数パラメーターもVIDもホップサブTLVに存在しません。

3. Edge Bridge (B) flag (1 bit): The Edge Bridge flag is a one-bit flag to indicate whether or not the given System is an Edge Bridge, i.e., transmitter and/or receiver. If the System is an Edge Bridge, then the Edge Bridge flag MUST be set. The Edge Bridge flag indicates that FDB entries have to be installed for the given hop as specified by the SPBV MAC address sub-TLV or SPBM Service Identifier and Unicast Address sub-TLV of the hop.

3. エッジブリッジ(B)フラグ(1ビット):エッジブリッジフラグは、指定されたシステムがエッジブリッジ、つまりトランスミッターまたはレシーバーであるかどうかを示す1ビットのフラグです。システムがエッジブリッジの場合、エッジブリッジフラグを設定する必要があります。エッジブリッジフラグは、ホップのSPBV MACアドレスサブTLVまたはSPBMサービスIDおよびユニキャストアドレスサブTLVで指定されているように、特定のホップに対してFDBエントリをインストールする必要があることを示します。

4. Root (R) flag (1 bit): The Root flag is a one-bit flag to indicate whether or not the given System is a root of the explicit tree specified by the Topology sub-TLV. If the System is a root of a tree, then the Root flag MUST be set. If the Topology sub-TLV specifies a single tree, i.e., the Base VIDs conveyed by the Topology sub-TLV are associated with either the ST ECT Algorithm or the LT ECT Algorithm (Section 5), then the Root flag is only set for one of the Systems conveyed by the Topology sub-TLV. Furthermore, the first Hop sub-TLV of the Topology sub-TLV conveys the System that is the root of the tree. If the Topology sub-TLV specifies a Loose Tree Set, i.e., the Base VIDs conveyed by the Topology sub-TLV are associated with the LTS ECT Algorithm (Section 5), then the Root flag is set for each Edge Bridge as each of them roots a tree. If the Topology sub-TLV is used for MRT operations, i.e., the Base VIDs conveyed by the Topology sub-TLV are associated with either the MRT ECT Algorithm or the MRTG ECT algorithm (Section 5), then the Root flag is set for each MRT Root. If no MRT Root is specified by a Topology sub-TLV specifying a GADAG, then each SPT Root is an MRT Root as well.

4. ルート(R)フラグ(1ビット):ルートフラグは、特定のシステムがトポロジサブTLVによって指定された明示的なツリーのルートであるかどうかを示す1ビットのフラグです。システムがツリーのルートである場合、ルートフラグを設定する必要があります。トポロジサブTLVが単一のツリーを指定する場合、つまり、トポロジサブTLVによって伝達されるベースVIDがST ECTアルゴリズムまたはLT ECTアルゴリズムのいずれかに関連付けられている場合(セクション5)、ルートフラグは1つだけに設定されます。トポロジサブTLVによって伝達されるシステムの。さらに、トポロジサブTLVの最初のホップサブTLVは、ツリーのルートであるシステムを伝達します。トポロジサブTLVがルーズツリーセットを指定している場合、つまり、トポロジサブTLVによって伝達されたベースVIDがLTS ECTアルゴリズムに関連付けられている場合(セクション5)、ルートフラグがそれぞれのエッジブリッジに設定されます。木を根にします。トポロジサブTLVがMRT操作に使用される場合、つまり、トポロジサブTLVによって伝達されるベースVIDがMRT ECTアルゴリズムまたはMRTG ECTアルゴリズムのいずれかに関連付けられている場合(セクション5)、それぞれにルートフラグが設定されます。 MRTルート。 GADAGを指定するトポロジサブTLVによってMRTルートが指定されていない場合、各SPTルートもMRTルートになります。

If the Base VIDs conveyed by the Topology sub-TLV are associated with the MRTG ECT algorithm (Section 5), then the Topology sub-TLV specifies a GADAG and the very first Hop sub-TLV specifies the GADAG Root. There is no flag for indicating the GADAG Root.

トポロジサブTLVによって伝達されるベースVIDがMRTG ECTアルゴリズムに関連付けられている場合(セクション5)、トポロジサブTLVはGADAGを指定し、最初のホップサブTLVはGADAGルートを指定します。 GADAG Rootを示すフラグはありません。

5. Leaf (L) flag (1 bit): The Leaf flag is a one-bit flag to indicate whether or not the given System is a leaf of the explicit tree specified by the Topology sub-TLV. If the System is a leaf, then the Leaf flag MUST be set. The Leaf flag is only used to mark a leaf of a tree if the Topology sub-TLV specifies a single tree. The Leaf flag MUST be used to indicate the end of a topology block if the Topology sub-TLV specifies a GADAG, see Section 7.

5. リーフ(L)フラグ(1ビット):リーフフラグは、指定されたシステムがトポロジサブTLVによって指定された明示的なツリーのリーフであるかどうかを示す1ビットのフラグです。システムが葉の場合、葉フラグを設定する必要があります。リーフフラグは、トポロジサブTLVが単一のツリーを指定している場合にのみ、ツリーの葉をマークするために使用されます。トポロジサブTLVがGADAGを指定している場合は、リーフフラグを使用してトポロジブロックの終了を示す必要があります。セクション7を参照してください。

6. Exclude (E) flag (1 bit): The Exclude flag is a one-bit flag to indicate if the given System MUST be excluded from the topology. The Exclude flag and the Root flag cannot be set for a given hop at the same time.

6. 除外(E)フラグ(1ビット):除外フラグは、特定のシステムをトポロジーから除外する必要があるかどうかを示す1ビットのフラグです。除外フラグとルートフラグを特定のホップに同時に設定することはできません。

7. Reserved (Res) (2 bits): The reserved bits MUST be set to 0 on transmission, and the value MUST be ignored on reception.

7. 予約済み(Res)(2ビット):予約済みビットは送信時に0に設定する必要があり、値は受信時に無視する必要があります。

d. System ID (48 bits): The six-byte IS-IS System Identifier of the bridge to which the Hop sub-TLV refers.

d. システムID(48ビット):ホップサブTLVが参照するブリッジの6バイトのIS-ISシステム識別子。

e. Extended Local Circuit ID (32 bits): The Extended Local Circuit ID [RFC5303] parameter is not necessarily present in the Hop sub-TLV. Its presence is indicated by the Circuit flag. Parallel links corresponding to different IS-IS adjacencies between a pair of neighbor bridges can be distinguished by means of the Extended Local Circuit ID. The Extended Local Circuit ID is conveyed by the Hop sub-TLV specifying the bridge nearer to the root of the tree, and identifies a circuit that attaches the given bridge to its neighbor cited by the next Hop sub-TLV of the Topology sub-TLV. The Extended Local Circuit ID can only be used in strict trees.

e. 拡張ローカル回線ID(32ビット):拡張ローカル回線ID [RFC5303]パラメータは、ホップサブTLVに必ずしも存在しません。その存在はCircuitフラグで示されます。隣接ブリッジのペア間の異なるIS-IS隣接に対応するパラレルリンクは、拡張ローカルサーキットIDによって区別できます。拡張ローカルサーキットIDは、ツリーのルートに最も近いブリッジを指定するホップサブTLVによって伝達され、トポロジサブTLVの次のホップサブTLVによって引用されたネイバーに特定のブリッジを接続する回路を識別します。 。拡張ローカルサーキットIDは、厳密なツリーでのみ使用できます。

f. Number of VIDs (8 bits): The Number of VIDs parameter is not present if the Hop sub-TLV does not convey VIDs, which is indicated by the VID flag.

f. VIDの数(8ビット):ホップサブTLVがVIDを伝達しない場合、VIDフラグで示されるVIDの数パラメーターは存在しません。

g. VID and its T/R flags (14 bits): The VID and its T/R flags are only present in the Hop sub-TLV if the given bridge is an Edge Bridge and it behaves differently from the default with respect to that particular VID.

g. VIDとそのT / Rフラグ(14ビット):特定のブリッジがエッジブリッジであり、特定のVIDに関してデフォルトとは異なる動作をする場合、VIDとそのT / RフラグはホップサブTLVにのみ存在します。 。

1. T flag (1 bit): This is the Transmit allowed flag for the VID following the flag.

1. Tフラグ(1ビット):これは、フラグに続くVIDの送信許可フラグです。

2. R flag (1 bit): This is the Receive allowed flag for the VID following the flag.

2. Rフラグ(1ビット):これは、フラグに続くVIDの受信許可フラグです。

3. Reserved (Res) (2 bits): The reserved bits MUST be set to 0 on transmission, and the value MUST be ignored on reception.

3. 予約済み(Res)(2ビット):予約済みビットは送信時に0に設定する必要があり、値は受信時に無視する必要があります。

4. VID (12 bits): A VID.

4. VID(12ビット):VID。

h. Delay Constraint (48 bits): A Hop sub-TLV MAY specify a delay constraint. The Length of the Hop sub-TLV indicates whether or not a delay constraint is present because the Length of a Hop sub-TLV conveying a delay constraint is six bytes greater than it would be without the delay constraint. The last six bytes then specify a delay constraint if they convey a Unidirectional Link Delay sub-TLV [RFC7810]. The delay constraint MAY be used in a Topology sub-TLV that specifies a single loose tree, i.e., the Base VIDs are associated with the LT ECT Algorithm (Section 5). If the delay constraint is applied, then the loose hop MUST fit in the delay budget specified by the Delay parameter of the Unidirectional Link Delay sub-TLV conveyed by the Hop sub-TLV. If the Topology sub-TLV specifies a single leaf, then the path between the preceding Hop sub-TLV and the current Hop sub-TLV MUST meet the delay budget. If the Topology sub-TLV specifies multiple leaves, then the path between the root and the current Hop sub-TLV MUST to meet the delay budget. If the tree is used as a reverse congruent tree, then the delay constraint applies in both directions. If the tree is used as a directed tree, then the delay constraint applies in the direction of the tree. If it is not possible to meet the delay constraint specified by the Topology sub-TLV, then no tree is installed but a management report is generated.

h. 遅延制約(48ビット):ホップサブTLVは遅延制約を指定できます(MAY)。ホップサブTLVの長さは、遅延制約が存在するかどうかを示します。これは、遅延制約を伝えるホップサブTLVの長さが、遅延制約がない場合よりも6バイト大きいためです。最後の6バイトは、単方向リンク遅延サブTLV [RFC7810]を伝える場合、遅延制約を指定します。遅延制約は、単一のルーズツリーを指定するトポロジサブTLVで使用される場合があります。つまり、ベースVIDはLT ECTアルゴリズムに関連付けられています(セクション5)。遅延制約が適用される場合、ルーズホップは、ホップサブTLVによって伝達される単方向リンク遅延サブTLVの遅延パラメーターで指定された遅延バジェットに収まる必要があります。トポロジサブTLVが単一のリーフを指定する場合、先行するホップサブTLVと現在のホップサブTLVの間のパスは、遅延バジェットを満たす必要があります。トポロジサブTLVが複数のリーフを指定する場合、ルートと現在のホップサブTLVの間のパスは、遅延バジェットを満たす必要があります。ツリーが逆合同ツリーとして使用される場合、遅延制約は両方向に適用されます。ツリーが有向ツリーとして使用される場合、遅延制約はツリーの方向に適用されます。トポロジサブTLVで指定された遅延制約を満たすことができない場合、ツリーはインストールされませんが、管理レポートが生成されます。

6.3. Bandwidth Constraint Sub-TLV
6.3. 帯域幅制約サブTLV

The Bandwidth Constraint sub-TLV MAY be included in a Topology sub-TLV (Section 6.1) in order to specify how much available bandwidth is to be provided by the constrained tree. Each loose hop MUST meet the bandwidth constraint. The bandwidth value of the constraint is a total value or it only refers to a single PCP as specified by the sub-TLV. Figure 4 shows the format of the Bandwidth Constraint sub-TLV.

帯域幅制約サブTLVは、制約付きツリーによって提供される利用可能な帯域幅の量を指定するために、トポロジサブTLV(セクション6.1)に含めることができます(MAY)。それぞれのルーズホップは、帯域幅の制約を満たす必要があります。制約の帯域幅値は合計値であるか、サブTLVで指定された単一のPCPのみを参照します。図4は、帯域幅制約サブ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      |                   (1 byte)
     +-+-+-+-+-+-+-+-+
     |    Length     |                   (1 byte)
     +-+-+-+-+-+-+-+-+
     | PCP |D|P| Res |                   (1 byte)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Available Bandwidth  (4 bytes)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 4: Bandwidth Constraint Sub-TLV

図4:帯域幅制約サブTLV

The parameters of the bandwidth constraint are encoded as follows:

帯域幅制約のパラメーターは、次のようにエンコードされます。

a. Type (8 bits): The type of the sub-TLV, its value is 23.

a. タイプ(8ビット):サブTLVのタイプ。値は23です。

b. Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 5 bytes.

b. 長さ(8ビット):「値」フィールドに含まれるバイトの総数。長さフィールドの値は5バイトです。

c. PCP (4 bits): The Priority Code Point (PCP) parameter identifies the traffic class the Available Bandwidth parameter refers to, if any.

c. PCP(4ビット):Priority Code Point(PCP)パラメーターは、Available Bandwidthパラメーターが参照するトラフィッククラスを識別します(ある場合)。

d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) parameter. If the DEI parameter is clear, then the bandwidth constraint refers to committed information rate. If the DEI parameter is set, then the bandwidth constraint refers to the peak information rate.

d. DEI(D)(1ビット):これはDrop Eligible Indicator(DEI)パラメーターです。 DEIパラメータがクリアされている場合、帯域幅の制約は認定情報レートを指します。 DEIパラメータが設定されている場合、帯域幅制約はピーク情報レートを参照します。

e. PCP (P) flag (1 bit): If this flag is set, then the PCP parameter is taken into account.

e. PCP(P)フラグ(1ビット):このフラグが設定されている場合、PCPパラメーターが考慮されます。

f. Reserved (Res) (3 bits): The reserved bits MUST be set to 0 on transmission, and the value MUST be ignored on reception.

f. 予約済み(Res)(3ビット):予約済みビットは送信時に0に設定する必要があり、値は受信時に無視する必要があります。

g. Available Bandwidth (32 bits): The Available Bandwidth is specific to the traffic class identified by the PCP parameter if the PCP flag is set; otherwise, it is total bandwidth. In line with the bandwidth parameters specified in [RFC5305], the Available Bandwidth is encoded as a 32-bit IEEE floating-point number [IEEE754], and the units are bytes (not bits!) per second. When the Unreserved Bandwidth sub-TLV (sub-TLV type 11 specified by [RFC5305]) is used in a Layer 2 bridge network, the priority value encoded in the Unreserved Bandwidth sub-TLV provides the PCP, i.e., identifies a traffic class (not a setup priority level). Thus, the Available Bandwidth of a traffic class is easily comparable with the Unreserved Bandwidth stored in the TED for the given traffic class. The bandwidth constraint applies for both directions in case of symmetric explicit trees. Nevertheless, a VID associated with an explicit tree can be made unidirectional by means of the T/R flags belonging to the VID in the Hop sub-TLV (item g. in Section 6.2) of the Edge Bridges. If all the VIDs of the Topology sub-TLV (Section 6.1) are unidirectional and all belong to the traffic class identified by the PCP parameter of the Bandwidth Constraint sub-TLV, then it is enough to meet the bandwidth constraint in the direction applied for those VIDs.

g。利用可能な帯域幅(32ビット):PCPフラグが設定されている場合、利用可能な帯域幅は、PCPパラメータによって識別されるトラフィッククラスに固有です。それ以外の場合は、合計帯域幅です。 [RFC5305]で指定されている帯域幅パラメーターに沿って、Available Bandwidthは32ビットのIEEE浮動小数点数[IEEE754]としてエンコードされ、単位は1秒あたりのバイト(ビットではない!)です。 Unreserved BandwidthサブTLV([RFC5305]で指定されたサブTLVタイプ11)がレイヤー2ブリッジネットワークで使用されている場合、Unreserved BandwidthサブTLVでエンコードされた優先度値はPCPを提供します。つまり、トラフィッククラス(セットアップの優先度ではありません)。したがって、トラフィッククラスの利用可能な帯域幅は、所定のトラフィッククラスのTEDに保存されている予約されていない帯域幅と簡単に比較できます。対称的な明示的なツリーの場合、帯域幅の制約は両方向に適用されます。それにもかかわらず、明示的なツリーに関連付けられたVIDは、エッジブリッジのホップサブTLV(セクションgの項目g)のVIDに属するT / Rフラグを使用して単方向にすることができます。トポロジサブTLV(セクション6.1)のすべてのVIDが単方向であり、すべてが帯域幅制約サブTLVのPCPパラメータで識別されるトラフィッククラスに属している場合、適用される方向の帯域幅制約を満たすのに十分です。これらのVID。

6.4. Bandwidth Assignment Sub-TLV
6.4. 帯域幅割り当てサブTLV

IS-IS PCR MAY be used for recording bandwidth assignment for explicitly placed data traffic in a domain if MSRP is not used within the domain. If MSRP is used in a domain, then only MSRP performs reservations and IS-IS does not. Both MSRP and IS-IS MUST NOT be used to make bandwidth assignments in the same domain.

ドメイン内でMSRPが使用されていない場合、IS-IS PCRを使用して、ドメインに明示的に配置されたデータトラフィックの帯域幅割り当てを記録できます。 MSRPがドメインで使用される場合、MSRPのみが予約を実行し、IS-ISは予約を実行しません。 MSRPとIS-ISの両方を使用して、同じドメインで帯域幅を割り当てることはできません。

The Bandwidth Assignment sub-TLV can be used to define the amount of bandwidth whose assignment is to be recorded by IS-IS PCR at each hop of the explicit tree described by the corresponding Topology sub-TLV (Section 6.1). The Bandwidth Assignment sub-TLV is used by IS-IS PCR for the recording of bandwidth assignment for a traffic class identified by the PCP parameter of a VLAN tag. If precedence order has to be determined among bandwidth assignments in a domain with multiple PCEs, then IS-IS PCR does it as described below. If the bandwidth assignment specified by the Topology sub-TLV is not possible, e.g., due to overbooking, then bandwidth recording MUST NOT be performed and a management report is generated. If the Topology sub-TLV specifies a new valid explicit tree, then the tree is installed without bandwidth assignment. The Bandwidth Assignment sub-TLV is conveyed by a Topology sub-TLV (Section 6.1). Figure 5 shows the format of the Bandwidth Assignment sub-TLV.

帯域幅割り当てサブTLVを使用して、対応するトポロジサブTLV(セクション6.1)によって記述された明示的なツリーの各ホップでIS-IS PCRによって割り当てが記録される帯域幅の量を定義できます。 IS-IS PCRは、帯域幅割り当てサブTLVを使用して、VLANタグのPCPパラメータで識別されるトラフィッククラスの帯域幅割り当てを記録します。複数のPCEを使用するドメインの帯域幅割り当て間で優先順位を決定する必要がある場合、IS-IS PCRは以下のようにそれを行います。トポロジーサブTLVによって指定された帯域幅の割り当てが可能でない場合、たとえばオーバーブッキングが原因で、帯域幅の記録を実行してはならず(MUST NOT)、管理レポートが生成されます。トポロジサブTLVが新しい有効な明示的ツリーを指定する場合、ツリーは帯域幅割り当てなしでインストールされます。帯域幅割り当てサブTLVは、トポロジサブTLV(セクション6.1)によって伝達されます。図5に、帯域幅割り当てサブ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      |                   (1 byte)
     +-+-+-+-+-+-+-+-+
     |    Length     |                   (1 byte)
     +-+-+-+-+-+-+-+-+
     | PCP |D| Imp |R|                   (1 byte)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Bandwidth  (4 bytes)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 5: Bandwidth Assignment Sub-TLV

図5:帯域幅割り当てサブTLV

The parameters of the bandwidth assignment are encoded as follows:

帯域幅割り当てのパラメーターは、次のようにエンコードされます。

a. Type (8 bits): The type of the sub-TLV, its value is 24.

a. タイプ(8ビット):サブTLVのタイプ。値は24です。

b. Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 5 bytes.

b. 長さ(8ビット):「値」フィールドに含まれるバイトの総数。長さフィールドの値は5バイトです。

c. PCP (3 bits): The PCP parameter identifies the traffic class for which the bandwidth is to be assigned.

c. PCP(3ビット):PCPパラメータは、帯域幅が割り当てられるトラフィッククラスを識別します。

d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) parameter. If the DEI parameter is clear, then the bandwidth assignment is performed for providing the committed information rate. If the DEI parameter is set, then the bandwidth assignment is performed for providing the peak information rate.

d. DEI(D)(1ビット):これはDrop Eligible Indicator(DEI)パラメーターです。 DEIパラメータがクリアされている場合、認定情報レートを提供するために帯域幅の割り当てが実行されます。 DEIパラメータが設定されている場合、帯域幅の割り当ては、ピーク情報レートを提供するために実行されます。

e. Importance (Imp) (3 bits): This is the Importance parameter for determining precedence order among bandwidth assignments within a PCP as described below. A lower numerical value indicates more important bandwidth assignment within a PCP. The default value of the Importance parameter is 7.

e. 重要度(インプ)(3ビット):これは、以下で説明するように、PCP内の帯域幅割り当て間の優先順位を決定するための重要度パラメーターです。数値が小さいほど、PCP内でより重要な帯域幅割り当てを示します。 Importanceパラメータのデフォルト値は7です。

f. Reserved (R) (1 bit): The reserved bit MUST be set to 0 on transmission, and the value MUST be ignored on reception.

f. 予約済み(R)(1ビット):予約ビットは送信時に0に設定する必要があり、値は受信時に無視する必要があります。

g. Bandwidth (32 bits): This is the amount of bandwidth to be assigned for the traffic class identified by the PCP parameter. In line with the bandwidth values specified in [RFC5305], the Bandwidth parameter is encoded as a 32-bit IEEE floating-point number [IEEE754], and the units are bytes (not bits!) per second. The bandwidth assignment applies for both directions in case of symmetric explicit trees.

g. 帯域幅(32ビット):これは、PCPパラメータで識別されるトラフィッククラスに割り当てられる帯域幅の量です。 [RFC5305]で指定された帯域幅の値に合わせて、Bandwidthパラメータは32ビットのIEEE浮動小数点数[IEEE754]としてエンコードされ、単位は1秒あたりのバイト(ビットではない!)です。対称的な明示的なツリーの場合、帯域幅の割り当ては両方向に適用されます。

The PCEs are collectively responsible for making a consistent set of bandwidth assignments when IS-IS PCR is used for recording bandwidth allocations. If, despite that, precedence ordering is required among bandwidth assignments, then ordering based on the following parameters MUST be applied:

PCEは、IS-IS PCRを使用して帯域幅の割り当てを記録する場合、一貫した一連の帯域幅割り当てを行う責任があります。それにもかかわらず、帯域幅割り当て間で優先順位が必要な場合は、次のパラメーターに基づく順序を適用する必要があります。

1. PCP parameter of Bandwidth Assignment sub-TLV,

1. 帯域幅割り当てサブTLVのPCPパラメータ

2. Importance parameter of Bandwidth Assignment sub-TLV,

2. 帯域幅割り当てサブTLVの重要度パラメーター、

3. Timestamp sub-TLV (if present in the Topology sub-TLV).

3. タイムスタンプサブTLV(トポロジサブTLVに存在する場合)。

A bandwidth assignment takes precedence if it has a higher PCP, or a higher Importance within a PCP, or an earlier timestamp in case of equal Importance within a PCP. A bandwidth assignment associated with a timestamp takes precedence over a bandwidth assignment without a timestamp when PCP and Importance of different bandwidth assignments are both equal. If resolution is not possible based on the above parameters or they are not available, e.g., each bandwidth assignment lacks a timestamp or the precedence order has to be determined for the use of a VID, then the item is granted to the PCE whose LSP has the numerically lowest LSP ID.

帯域幅の割り当ては、PCPが高い場合、またはPCP内の重要度が高い場合、またはPCP内の重要度が等しい場合はタイムスタンプが早い場合に優先されます。タイムスタンプに関連付けられた帯域幅割り当ては、PCPと異なる帯域幅割り当ての重要度の両方が等しい場合、タイムスタンプなしの帯域幅割り当てよりも優先されます。上記のパラメーターに基づいて解決できない場合、またはそれらが利用できない場合、たとえば、各帯域幅の割り当てにタイムスタンプがないか、VIDを使用するための優先順位を決定する必要がある場合、LSPが設定されているPCEにアイテムが付与されます。数値的に最小のLSP ID。

6.5. Timestamp Sub-TLV
6.5. タイムスタンプサブTLV

The Timestamp sub-TLV MAY be included in a Topology sub-TLV (Section 6.1) in order to provide precedence order among equally important bandwidth assignments within a PCP as described in Section 6.4. Figure 6 shows the format of the Timestamp sub-TLV.

セクション6.4で説明されているように、PCP内の同等に重要な帯域幅割り当て間で優先順位を提供するために、タイムスタンプサブTLVをトポロジサブTLV(セクション6.1)に含めることができます(MAY)。図6は、タイムスタンプサブ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      |                   (1 byte)
     +-+-+-+-+-+-+-+-+
     |    Length     |                   (1 byte)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Time       (4 bytes)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 6: Timestamp Sub-TLV

図6:タイムスタンプサブTLV

The timestamp represents a positive time with respect to the Precision Time Protocol (PTP) epoch, and it is encoded as follows:

タイムスタンプは、Precision Time Protocol(PTP)エポックに関して正の時間を表し、次のようにエンコードされます。

a. Type (8 bits): The type of the sub-TLV; its value is 25.

a. タイプ(8ビット):サブTLVのタイプ。その値は25です。

b. Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 4 bytes.

b. 長さ(8ビット):「値」フィールドに含まれるバイトの総数。長さフィールドの値は4バイトです。

c. Time (32 bits): This is the time in units of seconds with respect to the PTP epoch.

c. 時間(32ビット):これは、PTPエポックに関する秒単位の時間です。

The Timestamp sub-TLV carries the seconds portion of PTP as specified by [IEEE1588]. The epoch is 1970-01-01 00:00:00 TAI (i.e., the PTP time does not include leap seconds).

タイムスタンプサブTLVは、[IEEE1588]で指定されているPTPの秒の部分を伝送します。エポックは1970-01-01 00:00:00 TAIです(つまり、PTP時間にはうるう秒は含まれません)。

7. MRT-FRR Application
7. MRT-FRRアプリケーション

The application of MRT by [IEEE8021Qca] is discussed in detail in [MRT-IEEE8021qca]. This section describes some special considerations for the use of the MRT Lowpoint algorithm [RFC7811], which are applicable both to the MRT ECT Algorithm and the MRTG ECT Algorithm. This section also explains details related to the MRTG ECT Algorithm and the application of the Topology sub-TLV in particular.

[IEEE8021Qca]によるMRTの適用については、[MRT-IEEE8021qca]で詳しく説明されています。このセクションでは、MRT Lowpointアルゴリズム[RFC7811]の使用に関するいくつかの特別な考慮事項について説明します。これらは、MRT ECTアルゴリズムとMRTG ECTアルゴリズムの両方に適用できます。このセクションでは、MRTG ECTアルゴリズムに関連する詳細と、特にトポロジサブTLVのアプリケーションについても説明します。

IS-IS PCR does not use the MRT Profile specified in [RFC7812]. IS-IS PCR only relies on the algorithm specification in [RFC7811]. Both the MRT ECT Algorithm and the MRTG ECT Algorithm use the MRT Lowpoint algorithm specified in [RFC7811].

IS-IS PCRは、[RFC7812]で指定されたMRTプロファイルを使用しません。 IS-IS PCRは、[RFC7811]のアルゴリズム仕様のみに依存しています。 MRT ECTアルゴリズムとMRTG ECTアルゴリズムはどちらも、[RFC7811]で指定されているMRTローポイントアルゴリズムを使用します。

The SPB Link Metric sub-TLV [RFC6329] specifies the metric of each link for IS-IS PCR including the MRT algorithms. If the SPB Link Metric values advertised by different ends of an adjacency are different, then the maximum value MUST be used. If equal cost (sub-)paths are found during the MRT computation, then the default tie-breaking specified by Section 11 of [RFC6329] MUST be used, which is based on the lower BridgeID. (The BridgeID is an 8-byte quantity whose upper 2 bytes are the node's BridgePriority and lower 6 bytes are the node's System ID.) Note that if MRTs are used for source-specific multicast (see [IEEE8021Qca] for details), then the bridges have to compute the MRTs of the other bridges in addition to their own in order to be able to install the appropriated FDB entries. (This is similar to the need for all pairs shortest path computation instead of Dijkstra for source-specific shortest path multicast trees.)

SPBリンクメトリックサブTLV [RFC6329]は、MRTアルゴリズムを含むIS-IS PCRの各リンクのメトリックを指定します。隣接の異なる端によってアドバタイズされるSPBリンクメトリック値が異なる場合、最大値を使用する必要があります。 MRTの計算中に等コストの(サブ)パスが見つかった場合は、[RFC6329]のセクション11で指定されているデフォルトのタイブレークを使用する必要があります。これは、低いBridgeIDに基づいています。 (BridgeIDは8バイトの量で、上位2バイトはノードのBridgePriorityで、下位6バイトはノードのシステムIDです。)MRTがソース固有のマルチキャストに使用されている場合(詳細については[IEEE8021Qca]を参照)、ブリッジは、適切なFDBエントリをインストールできるようにするために、ブリッジに加えて他のブリッジのMRTを計算する必要があります。 (これは、ソース固有の最短パスマルチキャストツリーの場合、ダイクストラではなく、すべてのペアの最短パス計算の必要性に似ています。)

The GADAG is identical for all the MRTs within a network domain, as a consequence of the use of the MRT Lowpoint algorithm [RFC7811]. Therefore, it is beneficial to compute the GADAG by a single entity, which is referred to as the GADAG Computer and is either a PCE or the GADAG Root. If the MRTG ECT Algorithm is applied, then the GADAG MUST be computed only by the GADAG Computer, which then MUST flood the descriptor Topology sub-TLV of the GADAG. The bridges then compute the MRTs based on the received GADAG.

GADAGは、MRT Lowpointアルゴリズム[RFC7811]を使用した結果として、ネットワークドメイン内のすべてのMRTで同一です。したがって、GADAGコンピューターと呼ばれ、PCEまたはGADAGルートのいずれかである単一のエンティティーによってGADAGを計算することは有益です。 MRTG ECTアルゴリズムが適用される場合、GADAGはGADAGコンピュータによってのみ計算される必要があり、GADAGコンピュータはGADAGの記述子トポロジサブTLVをフラッディングする必要があります。次に、ブリッジは受信したGADAGに基づいてMRTを計算します。

The GADAG computation requires the selection of the GADAG Root. The bridge with the best BridgeID MUST be selected as the GADAG Root, where the numerically lower value indicates the better identifier. The Bridge Priority component of the BridgeID allows the configuration of the GADAG Root by management action. The Bridge Priority is conveyed by the SPB Instance sub-TLV [RFC6329].

GADAG計算では、GADAGルートを選択する必要があります。最良のBridgeIDを持つブリッジをGADAG Rootとして選択する必要があります。数値が小さいほど、より良い識別子を示します。 BridgeIDのBridge Priorityコンポーネントを使用すると、管理アクションによってGADAGルートを構成できます。ブリッジ優先度は、SPBインスタンスサブTLV [RFC6329]によって伝えられます。

The GADAG Computer MUST perform the GADAG computation as specified by the MRT Lowpoint algorithm [RFC7811]. The GADAG Computer then MUST encode the GADAG in a Topology sub-TLV (Section 6.1), which is then flooded throughout the domain. A GADAG is encoded in a Topology sub-TLV by means of directed ear decomposition as follows. A directed ear is a directed point-to-point path whose end points can coincide but no other element of the path is repeated in the ear. Each ear is specified by an ordered list of hops such that the order of hops is according to the direction of the arcs in the GADAG. There are no leaves in a GADAG; hence, the Leaf flag (item c.5. in Section 6.2) is used to mark the end of a topology block. (A GADAG with multiple blocks is illustrated in Figure 8.) The sequence of ears in the Topology sub-TLV is such that the end points of an ear belong to preceding ears. The GADAG Root is not marked by any flag, but the GADAG Root is the first hop in the Topology sub-TLV; correspondingly, the first ear starts and ends with the GADAG Root. MRT Roots MUST be marked by the Root flag (item c.4. in Section 6.2) and all other Edge Bridges are leaves of the given MRTs. If no MRT Root is specified, then each SPT Root is also an MRT Root.

GADAGコンピューターは、MRTローポイントアルゴリズム[RFC7811]で指定されているGADAG計算を実行する必要があります。次に、GADAGコンピュータはGADAGをトポロジサブTLV(セクション6.1)にエンコードする必要があります。これは、ドメイン全体にフラッディングされます。 GADAGは、次のように有向耳分解によってトポロジサブTLVでエンコードされます。有向耳は、終点が一致することはできますが、耳内で経路の他の要素が繰り返されない有向ポイントツーポイントパスです。各耳は、ホップの順序がGADAG内の弧の方向に従うように、ホップの順序付きリストによって指定されます。 GADAGには葉がありません。したがって、Leafフラグ(セクション6.2の項目c.5。)を使用して、トポロジブロックの終わりを示します。 (複数のブロックを持つGADAGを図8に示します。)トポロジサブTLVの耳のシーケンスは、耳のエンドポイントが先行する耳に属するようになっています。 GADAGルートはフラグでマークされていませんが、GADAGルートはトポロジサブTLVの最初のホップです。それに対応して、最初の耳はGADAG Rootで始まり、GADAG Rootで終わります。 MRTルートはルートフラグ(セクション6.2の項目c.4)でマークする必要があり、他のすべてのエッジブリッジは指定されたMRTのリーフです。 MRTルートが指定されていない場合、各SPTルートもMRTルートです。

Figure 7 shows an example GADAG. The figure also illustrates the description of the GADAG; it shows the System ID parameter of the Hop sub-TLV (Section 6.2) and the order of hops in the Topology sub-TLV (Section 6.1).

図7にGADAGの例を示します。この図は、GADAGの説明も示しています。ホップサブTLV(セクション6.2)のシステムIDパラメーターとトポロジサブTLV(セクション6.1)でのホップの順序を示しています。

                                                       Leaf
                                               Hop     flag
                                          +-----------+---+
                                          |     A     |   |
                                          +-----------+---+
                                          |     B     |   |
                                          +-----------+---+
                                          |     C     |   |
                                          +-----------+---+
                                          |     F     |   |
               [B]<---[A]<---[I]          +-----------+---+
                |      ^      ^           |     A     |   |
                |      |      |           +-----------+---+
                V      |      |           |     C     |   |
               [C]--->[F]--->[H]          +-----------+---+
                |             ^           |     D     |   |
                |             |           +-----------+---+
                V             |           |     E     |   |
               [D]--->[E]--->[G]          +-----------+---+
                                          |     G     |   |
                                          +-----------+---+
                                          |     H     |   |
                                          +-----------+---+
                                          |     I     |   |
                                          +-----------+---+
                                          |     A     |   |
                                          +-----------+---+
                                          |     F     |   |
                                          +-----------+---+
                                          |     H     | X |
                                          +-----------+---+
        
        Figure 7: A GADAG and Its Description; GADAG Root = Node A
        

A topology can comprise multiple blocks, like the one illustrated in Figure 8(a). This example topology comprises four blocks as each cut-link is a block. A-B-C-D-E-F is a block, D-G is another block, G-H, and H-J-K are further blocks. A GADAG for this topology is shown in Figure 8(b). Note that two arcs with opposite directions represent a cut-link in a GADAG; see, for example, the cut-link between D and G. The encoding starts with the block (ADAG) involving the GADAG Root as illustrated in Figure 8. The first hop in the Topology sub-TLV is the GADAG Root (node A in this example). The ADAG of the first block is then described using the ear decomposition, as described above. In this example, the first block has been completely traversed at the second occurrence of node A in the GADAG descriptor. The end of a block is indicated by setting the Leaf flag for the last hop of the block, e.g., for the second occurrence of node A in the example GADAG descriptor. The next node that appears in the GADAG descriptor (D in this case) is the localroot for the nodes in the next block. Continuing this process, the Leaf flag is set for the third occurrence of D, the third occurrence of G, and the third occurrence of H, each indicating the end of a block. The first hop of the first block is the GADAG Root, the fist hop in the rest of the blocks is the localroot. The position of the set Leaf flags helps to determine the localroot, which is the next hop. In the example GADAG descriptor, one can determine that A is the localroot for B, C, D, E, F (and A is the GADAG Root). D is the localroot for G. G is the localroot for H. And H is the localroot for J and K. The GADAG Root is assigned a localroot of None.

トポロジは、図8(a)に示すような複数のブロックで構成できます。この例のトポロジは、各カットリンクがブロックであるため、4つのブロックで構成されています。 A-B-C-D-E-Fはブロック、D-Gは別のブロック、G-H、H-J-Kはさらにブロックです。このトポロジのGADAGを図8(b)に示します。反対方向の2つの弧はGADAGのカットリンクを表すことに注意してください。たとえば、DとGの間のカットリンクを参照してください。エンコーディングは、図8に示すように、GADAGルートを含むブロック(ADAG)から始まります。トポロジサブTLVの最初のホップはGADAGルート(のノードA)です。この例)。次に、上記のように、最初のブロックのADAGが耳分解を使用して記述されます。この例では、最初のブロックは、GADAG記述子のノードAの2番目のオカレンスで完全にトラバースされています。ブロックの最後は、ブロックの最後のホップにリーフフラグを設定することで示されます(例:GADAG記述子の例でノードAが2回目に出現する場合)。 GADAG記述子に表示される次のノード(この場合はD)は、次のブロックのノードのローカルルートです。このプロセスを続けると、リーフフラグは、Dの3番目の出現、Gの3番目の出現、およびHの3番目の出現に対して設定され、それぞれブロックの終わりを示します。最初のブロックの最初のホップはGADAG Rootで、残りのブロックの最初のホップはlocalrootです。セットされたリーフフラグの位置は、次のホップであるlocalrootを決定するのに役立ちます。 GADAG記述子の例では、AがB、C、D、E、Fのローカルルートである(およびAがGADAGルートである)と判断できます。 DはGのローカルルートです。GはHのローカルルートです。HはJとKのローカルルートです。GADAGルートには、Noneのローカルルートが割り当てられています。

Block IDs are reconstructed while parsing a Topology sub-TLV specifying a GADAG. The current Block ID starts at 0 and is assigned to the GADAG Root. A node appearing in the GADAG descriptor without a previously assigned Block ID value is assigned the current Block ID. And the current Block ID is incremented by 1 after processing the localroot of a block. Note that the localroot of a block will keep the Block ID of the first block in which it is assigned a Block ID. In the example in Figure 8, A has Block ID=0. B, C, D, E, and F have Block ID=1. G has Block ID=2. H has Block ID=3. J and K have Block ID=4.

GADAGを指定するトポロジサブTLVの解析中に、ブロックIDが再構築されます。現在のブロックIDは0から始まり、GADAGルートに割り当てられます。以前にブロックID値が割り当てられていないGADAG記述子に表示されるノードには、現在のブロックIDが割り当てられます。また、現在のブロックIDは、ブロックのローカルルートを処理した後に1ずつ増加します。ブロックのローカルルートは、ブロックIDが割り当てられている最初のブロックのブロックIDを保持することに注意してください。図8の例では、AのブロックIDは0です。 B、C、D、E、およびFのブロックIDは1です。 GのブロックIDは2です。 HのブロックIDは3です。 JとKのブロックIDは4です。

                                                       Leaf
                                               Hop     flag
               [F]--[E]        +--[K]     +-----------+---+
                |    |         |   |      |     A     |   |
                |    |         |   |      +-----------+---+
               [A]  [D]--[G]--[H]  |      |     B     |   |
                |    |         |   |      +-----------+---+
                |    |         |   |      |     C     |   |
               [B]--[C]        +--[J]     +-----------+---+
                                          |     D     |   |
                    (a) Topology          +-----------+---+
                                          |     E     |   |
                                          +-----------+---+
                                          |     F     |   |
                                          +-----------+---+
                                          |     A     | X |
                                          +-----------+---+
               +-+  +-+           +-+     |     D     |   |
               |F|<-|E|        +--|K|     +-----------+---+
               +-+  +-+        |  +-+     |     G     |   |
                |    ^         |   ^      +-----------+---+
                |    |         V   |      |     D     | X |
                V   +-+  +-+  +-+  |      +-----------+---+
               +-+  | |->| |->| |  |      |     G     |   |
               |A|  |D|  |G|  |H|  |      +-----------+---+
               +-+  | |<-| |<-| |  |      |     H     |   |
                |   +-+  +-+  +-+  |      +-----------+---+
                |    ^         |   |      |     G     | X |
                V    |         |   |      +-----------+---+
               +-+  +-+        |  +-+     |     H     |   |
               |B|->|C|        +->|J|     +-----------+---+
               +-+  +-+           +-+     |     J     |   |
                                          +-----------+---+
                     (b) GADAG            |     K     |   |
                                          +-----------+---+
                                          |     H     | X |
                                          +-----------+---+
        

(c) GADAG Descriptor

(c)GADAG記述子

Figure 8: A GADAG with Cut-Links and Its Description; GADAG Root = Node A

図8:カットリンクを含むGADAGとその説明。 GADAGルート=ノードA

8. Summary
8. 概要

This document specifies IS-IS sub-TLVs for the control of explicit trees in Layer 2 networks. These sub-TLVs can be also used for the distribution of a centrally computed GADAG or MRTs if MFT-FRR is used.

このドキュメントでは、レイヤ2ネットワークで明示的なツリーを制御するためのIS-ISサブTLVを指定しています。これらのサブTLVは、MFT-FRRが使用されている場合、中央で計算されたGADAGまたはMRTの配布にも使用できます。

9. IANA Considerations
9. IANAに関する考慮事項

This document defines the following IS-IS sub-TLVs within the MT-Capability TLV (type 144). They are listed in the "IS-IS TLV Codepoints" registry.

このドキュメントでは、MT機能TLV(タイプ144)内の次のIS-ISサブTLVを定義します。それらは「IS-IS TLVコードポイント」レジストリにリストされています。

         Type        Description                           Length
         ----        ----------------------------        --------
           21        Topology                            variable
           22        Hop                                 variable
           23        Bandwidth Constraint                       5
           24        Bandwidth Assignment                       5
           25        Timestamp                                  4
        
10. Security Considerations
10. セキュリティに関する考慮事項

This document adds no additional security risks to IS-IS, nor does it provide any additional security for IS-IS when used in a configured environment or a single-operator domain such as a data center. IS-IS PCR is not for zero-configuration environments.

このドキュメントは、IS-ISに追加のセキュリティリスクを追加することはありません。また、構成された環境またはデータセンターなどの単一オペレータードメインで使用される場合、IS-ISに追加のセキュリティを提供しません。 IS-IS PCRは、ゼロ構成環境用ではありません。

Any mechanism that chooses forwarding paths, and allocates resources to those paths, is potentially vulnerable to attack. The security considerations section of [RFC4655] describes the risks associated with the use of PCE for this purpose and should be referred to. Use of any other means to determine paths should only be used after considering similar concerns.

転送パスを選択し、それらのパスにリソースを割り当てるメカニズムは、攻撃に対して潜在的に脆弱です。 [RFC4655]のセキュリティに関する考慮事項のセクションでは、この目的でのPCEの使用に関連するリスクについて説明しており、参照する必要があります。パスを決定するための他の手段の使用は、同様の懸念事項を検討した後にのみ使用する必要があります。

Because the mechanism assumed for distributing tree information relies on IS-IS routing, IS-IS routing security considerations (Section 6, [RFC1195]) and mechanisms (e.g., [RFC5310]) used to authenticate peer advertisements apply.

ツリー情報を配信するために想定されているメカニズムはIS-ISルーティングに依存しているため、IS-ISルーティングのセキュリティに関する考慮事項(セクション6、[RFC1195])とピアアドバタイズメントの認証に使用されるメカニズム([RFC5310]など)が適用されます。

11. References
11. 参考文献
11.1. Normative References
11.1. 引用文献

[IEEE8021Qca] IEEE, "IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Amendment 24: Path Control and Reservation", IEEE 802.1Qca-2015, DOI 10.1109/IEEESTD.2016.7434544, 2016, <https://standards.ieee.org/findstds/ standard/802.1Qca-2015.html>.

[IEEE8021Qca] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks-Amendment 24:Path Control and Reservation」、IEEE 802.1Qca-2015、DOI 10.1109 / IEEESTD.2016.7434544、2016、<https:// standards .ieee.org / findstds / standard / 802.1Qca-2015.html>。

[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>。

[RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, DOI 10.17487/RFC5303, October 2008, <http://www.rfc-editor.org/info/rfc5303>.

[RFC5303] Katz、D.、Saluja、R。、およびD. Eastlake 3番目、「IS-ISポイントツーポイント隣接のための3ウェイハンドシェイク」、RFC 5303、DOI 10.17487 / RFC5303、2008年10月、<http: //www.rfc-editor.org/info/rfc5303>。

[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>。

[RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012, <http://www.rfc-editor.org/info/rfc6329>.

[RFC6329] Fedyk、D.、Ed。、Ashwood-Smith、P.、Ed。、Allan、D.、Bragg、A.、and P. Unbehagen、 "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging"、 RFC 6329、DOI 10.17487 / RFC6329、2012年4月、<http://www.rfc-editor.org/info/rfc6329>。

[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, <http://www.rfc-editor.org/info/rfc7810>.

[RFC7810] Previdi、S.、Ed。、Giacalone、S.、Ward、D.、Drake、J.、and Q. Wu、 "IS-IS Traffic Engineering(TE)Metric Extensions"、RFC 7810、DOI 10.17487 / RFC7810、2016年5月、<http://www.rfc-editor.org/info/rfc7810>。

[RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, DOI 10.17487/RFC7811, June 2016, <http://www.rfc-editor.org/info/rfc7811>.

[RFC7811] Enyedi、G.、Csaszar、A.、Atlas、A.、Bowers、C。、およびA. Gopalan、「最大冗長ツリー(MRT-FRR)を使用してIP / LDP高速リルートを計算するアルゴリズム」、RFC 7811、DOI 10.17487 / RFC7811、2016年6月、<http://www.rfc-editor.org/info/rfc7811>。

11.2. Informative References
11.2. 参考引用

[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, 2008, <http://standards.ieee.org/findstds/ standard/1588-2008.html>.

[IEEE1588] IEEE、「ネットワーク化された測定および制御システムの高精度クロック同期プロトコルのIEEE標準」、IEEE 1588-2008、DOI 10.1109 / IEEESTD.2008.4579760、2008、<http://standards.ieee.org/findstds/ standard /1588-2008.html>。

[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935, 2008, <http://standards.ieee.org/findstds/ standard/754-2008.html>.

[IEEE754] IEEE、「IEEE Standard for Floating-Point Arithmetic」、IEEE 754-2008、DOI 10.1109 / IEEESTD.2008.4610935、2008、<http://standards.ieee.org/findstds/ standard / 754-2008.html> 。

[IEEE8021aq] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks -- Amendment 20: Shortest Path Bridging", IEEE 802.1aq-2012, DOI 10.1109/IEEESTD.2012.6231597, 2012, <https://standards.ieee.org/findstds/ standard/802.1aq-2012.html>.

[IEEE8021aq] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control(MAC)Bridges and Virtual Bridged Local Area Networks-Amendment 20:Shortest Path Bridging」、IEEE 802.1aq-2012、DOI 10.1109 / IEEESTD。 2012.6231597、2012、<https://standards.ieee.org/findstds/ standard / 802.1aq-2012.html>。

[IEEE8021Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, 2014, <https://standards.ieee.org/findstds/ standard/802.1Q-2014.html>.

[IEEE8021Q] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-ブリッジおよびブリッジネットワーク」、IEEE 802.1Q-2014、DOI 10.1109 / IEEESTD.2014.6991462、2014、<https://standards.ieee.org/findstds/ standard / 802.1Q-2014.html>。

[MRT-IEEE8021qca] Bowers, C. and J. Farkas, "Applicability of Maximally Redundant Trees to IEEE 802.1Qca Path Control and Reservation", Work in Progress, draft-bowers-rtgwg-mrt-applicability-to-8021qca-01, July 2015.

[MRT-IEEE8021qca] Bowers、C。およびJ. Farkas、「最大冗長ツリーのIEEE 802.1Qcaパス制御および予約への適用性」、作業中、draft-bowers-rtgwg-mrt-applicability-to-8021qca-01、 2015年7月。

[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <http://www.rfc-editor.org/info/rfc1195>.

[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、DOI 10.17487 / RFC1195、1990年12月、<http://www.rfc-editor.org/ info / rfc1195>。

[RFC4655] Farrel, A., Vasseur, J., 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、J。、およびJ. Ash、「A Path Computation Element(PCE)-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<http://www.rfc -editor.org/info/rfc4655>。

[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.

[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。

[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, <http://www.rfc-editor.org/info/rfc7812>.

[RFC7812] Atlas、A.、Bowers、C。、およびG. Enyedi、「最大冗長ツリー(MRT-FRR)を使用したIP / LDP高速リルートのアーキテクチャ」、RFC 7812、DOI 10.17487 / RFC7812、2016年6月、< http://www.rfc-editor.org/info/rfc7812>。

Acknowledgements

謝辞

The authors would like to thank Don Fedyk and Eric Gray for their comments and suggestions.

著者は、コメントと提案をしてくれたDon FedykとEric Grayに感謝します。

Authors' Addresses

著者のアドレス

Janos Farkas (editor) Ericsson Konyves Kalman krt. 11/B Budapest 1097 Hungary

Janos Farkas(編集者)Ericsson Konyves Kalman krt。 11 / Bブダペスト1097ハンガリー

   Email: janos.farkas@ericsson.com
        

Nigel Bragg Ciena 43-51 Worship Street London EC2A 2DX United Kingdom

Nigel Bragg Ciena 43-51 Worship Street London EC2A 2DXイギリス

   Email: nbragg@ciena.com
        

Paul Unbehagen Jr Avaya 1300 W. 120th Avenue Westminster, CO 80234 United States

Paul Discomfort Jr Avaya 1300 W. 120th Avenue Westminster、CO 80234アメリカ合衆国

   Email: unbehagen@avaya.com
        

Glenn Parsons Ericsson 349 Terry Fox Drive Ottawa ON, K2K 2V6 Canada

Glenn Parsons Ericsson 349 Terry Fox Driveオタワオン、K2K 2V6カナダ

Email: glenn.parsons@ericsson.com Peter Ashwood-Smith Huawei Technologies 303 Terry Fox Drive, Suite 400 Ottawa ON, K2K 3J1 Canada

メール:glenn.parsons@ericsson.com Peter Ashwood-Smith Huawei Technologies 303 Terry Fox Drive、Suite 400 Ottawa ON、K2K 3J1 Canada

   Email: Peter.AshwoodSmith@huawei.com
        

Chris Bowers Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States

Chris Bowers Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国

   Email: cbowers@juniper.net