[要約] RFC 8454は、ACTN（TEネットワークの抽象化と制御のための情報モデル）に関する情報モデルを提供しています。このRFCの目的は、ネットワークリソースの抽象化と制御を容易にするための枠組みを提供することです。
Internet Engineering Task Force (IETF) Y. Lee
Request for Comments: 8454 Huawei
Category: Informational S. Belotti
ISSN: 2070-1721 Nokia
D. Dhody
Huawei
D. Ceccarelli
Ericsson
B. Yoon
ETRI
September 2018
Information Model for Abstraction and Control of TE Networks (ACTN)
ネットワークの抽象化と制御のための情報モデル（ACT）
Abstract
概要
This document provides an information model for Abstraction and Control of TE Networks (ACTN).
このドキュメントでは、TEネットワークの抽象化と制御（ACTN）の情報モデルについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8454.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8454で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. ACTN Common Interfaces Information Model . . . . . . . . . . 5
3. Virtual Network Primitives . . . . . . . . . . . . . . . . . 6
3.1. VN Instantiate . . . . . . . . . . . . . . . . . . . . . 7
3.2. VN Modify . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. VN Delete . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. VN Update . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. VN Compute . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. VN Query . . . . . . . . . . . . . . . . . . . . . . . . 8
4. TE Primitives . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. TE Instantiate . . . . . . . . . . . . . . . . . . . . . 9
4.2. TE Modify . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. TE Delete . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. TE Topology Update (for TE Resources) . . . . . . . . . . 9
4.5. Path Compute . . . . . . . . . . . . . . . . . . . . . . 10
5. VN Objects . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. VN Identifier . . . . . . . . . . . . . . . . . . . . . . 11
5.2. VN Service Characteristics . . . . . . . . . . . . . . . 11
5.3. VN Endpoint . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. VN Objective Function . . . . . . . . . . . . . . . . . . 14
5.5. VN Action Status . . . . . . . . . . . . . . . . . . . . 14
5.6. VN Topology . . . . . . . . . . . . . . . . . . . . . . . 15
5.7. VN Member . . . . . . . . . . . . . . . . . . . . . . . . 15
5.7.1. VN Computed Path . . . . . . . . . . . . . . . . . . 15
5.7.2. VN Service Preference . . . . . . . . . . . . . . . . 16
6. TE Objects . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. TE Tunnel Characteristics . . . . . . . . . . . . . . . . 17
7. Mapping of VN Primitives with VN Objects . . . . . . . . . . 19
8. Mapping of TE Primitives with TE Objects . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
This document provides an information model for Abstraction and Control of TE Networks (ACTN). The information model described in this document covers the interface requirements identified in the ACTN Framework document [RFC8453].
このドキュメントでは、TEネットワークの抽象化と制御（ACTN）の情報モデルについて説明します。このドキュメントで説明されている情報モデルは、ACTNフレームワークドキュメント[RFC8453]で特定されているインターフェイス要件をカバーしています。
The ACTN reference architecture [RFC8453] identifies a three-tier control hierarchy comprising the following as depicted in Figure 1:
ACTNリファレンスアーキテクチャ[RFC8453]は、図1に示すように、以下を含む3層の制御階層を識別します。
o Customer Network Controllers (CNCs) o Multi-Domain Service Coordinator (MDSC) o Provisioning Network Controllers (PNCs)
o カスタマーネットワークコントローラー（CNC）oマルチドメインサービスコーディネーター（MDSC）oプロビジョニングネットワークコントローラー（PNC）
+-------+ +-------+ +-------+
| CNC-A | | CNC-B | | CNC-C |
+-------+ +-------+ +-------+
\ | /
------------ | CMI -------------
\ | /
+----------------------+
| MDSC |
+----------------------+
/ | \
------------ | MPI -------------
/ | \
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
Figure 1: A Three-Tier ACTN Control Hierarchy
図1：3層ACTN制御階層
The two interfaces with respect to the MDSC, one north of the MDSC and the other south of the MDSC, are referred to as "CMI" (CNC-MDSC Interface) and "MPI" (MDSC-PNC Interface), respectively. This document models these two interfaces and derivative interfaces thereof (e.g., MDSC-to-MDSC in a hierarchy of MDSCs) as a single common interface.
MDSCに関する2つのインターフェースは、MDSCの北とMDSCの南の2つで、それぞれ「CMI」（CNC-MDSCインターフェース）および「MPI」（MDSC-PNCインターフェース）と呼ばれます。このドキュメントは、これら2つのインターフェースとその派生インターフェース（MDSCの階層におけるMDSCからMDSCなど）を単一の共通インターフェースとしてモデル化します。
The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)" are defined in [RFC8453]. Other key terms and concepts, for example, "abstraction", can be found in [RFC7926].
「仮想ネットワーク（VN）」および「仮想ネットワークサービス（VNS）」という用語は、[RFC8453]で定義されています。 「抽象化」などの他の主要な用語と概念は、[RFC7926]にあります。
This section provides an ACTN common interface information model to describe primitives, objects, their properties (represented as attributes), their relationships, and the resources for the service applications needed in the ACTN context.
このセクションでは、プリミティブ、オブジェクト、それらのプロパティ（属性として表される）、それらの関係、およびACTNコンテキストで必要なサービスアプリケーションのリソースについて説明するためのACTN共通インターフェイス情報モデルを提供します。
The standard interface is described between a client controller and a server controller. A client-server relationship is recursive between a CNC and an MDSC and between an MDSC and a PNC. In the CMI, the client is a CNC while the server is an MDSC. In the MPI, the client is an MDSC and the server is a PNC. There may also be MDSC-MDSC interfaces that need to be supported. This may arise in a hierarchy of MDSCs in which workloads may need to be partitioned to multiple MDSCs.
標準インターフェイスは、クライアントコントローラーとサーバーコントローラーの間で記述されます。クライアントとサーバーの関係は、CNCとMDSCの間、およびMDSCとPNCの間で再帰的です。 CMIでは、クライアントはCNCであり、サーバーはMDSCです。 MPIでは、クライアントはMDSCであり、サーバーはPNCです。サポートする必要のあるMDSC-MDSCインターフェイスもある場合があります。これは、ワークロードを複数のMDSCに分割する必要があるMDSCの階層で発生する可能性があります。
Basic primitives (messages) are required between the CNC-MDSC and MDSC-PNC controllers. These primitives can then be used to support different ACTN network control functions like network topology requests/queries, VN service requests, path computation and connection control, VN service policy negotiation, enforcement, routing options, etc.
CNC-MDSCコントローラーとMDSC-PNCコントローラーの間には、基本的なプリミティブ（メッセージ）が必要です。これらのプリミティブを使用して、ネットワークトポロジ要求/クエリ、VNサービス要求、パス計算と接続制御、VNサービスポリシーネゴシエーション、施行、ルーティングオプションなどのさまざまなACTNネットワーク制御機能をサポートできます。
There are two different types of primitives depending on the type of interface:
インターフェイスのタイプに応じて、2つの異なるタイプのプリミティブがあります。
o Virtual Network primitives at CMI o Traffic Engineering primitives at MPI
o CMIの仮想ネットワークプリミティブo MPIのトラフィックエンジニアリングプリミティブ
As well described in [RFC8453], at the CMI level, there is no need for detailed TE information since the basic functionality is to translate customer service information into VNS operation.
[RFC8453]でも説明されているように、CMIレベルでは、基本的な機能はカスタマーサービス情報をVNSオペレーションに変換することなので、詳細なTE情報は必要ありません。
At the MPI level, MDSC has the main scope for multi-domain coordination and creation of a single end-to-end (E2E) abstracted network view that is strictly related to TE information.
MPSCレベルでは、MDSCは、マルチドメインの調整と、TE情報に厳密に関連する単一のエンドツーエンド（E2E）抽象ネットワークビューの作成のためのメインスコープを持っています。
As for topology, this document employs two types of topology.
トポロジに関しては、このドキュメントでは2種類のトポロジを採用しています。
o The first type is referred to as "virtual network topology" and is associated with a VN. Virtual network topology is a customized topology for view and control by the customer. See Section 3.1 for details.
o 最初のタイプは「仮想ネットワークトポロジ」と呼ばれ、VNに関連付けられます。仮想ネットワークトポロジは、お客様が表示および制御するためにカスタマイズされたトポロジです。詳細については、セクション3.1を参照してください。
o The second type is referred to as "TE topology" and is associated with provider network operation on which we can apply policy to obtain the required level of abstraction to represent the underlying physical network topology.
o 2番目のタイプは「TEトポロジ」と呼ばれ、ポリシーを適用して、基礎となる物理ネットワークトポロジを表すために必要な抽象化レベルを取得できるプロバイダーネットワーク操作に関連付けられます。
This section provides a list of main VN primitives related to VNs and that are necessary to satisfy the ACTN requirements specified in [ACTN-REQ].
このセクションでは、VNに関連し、[ACTN-REQ]で指定されているACTN要件を満たすために必要な主要なVNプリミティブのリストを提供します。
The following VN Action primitives are supported:
次のVNアクションプリミティブがサポートされています。
o VN Instantiate
o VNインスタンス化
o VN Modify
o VN修正
o VN Delete
o VN削除
o VN Update
o VNアップデート
o VN Path Compute
o VNパス計算
o VN Query
o VNクエリ
VN Action is an object describing the main VN primitives.
VNアクションは、主要なVNプリミティブを記述するオブジェクトです。
VN Action can assume one of the mentioned above primitives values.
VNアクションは、上記のプリミティブ値のいずれかを想定できます。
<VN Action> ::= <VN Instantiate> |
<VN Modify> |
<VN修正> |
<VN Delete> |
<VNシェア> |
<VN Update> |
<VNアップデート> |
<VN Path Compute> |
<VNパス計算> |
<VN Query>
<VNクエリ>
All these actions will solely happen at CMI level between CNC and MDSC.
これらすべてのアクションは、CNCとMDSCの間のCMIレベルでのみ発生します。
VN Instantiate refers to an action from customers/applications to request the creation of VNs. VN Instantiate is for CNC-to-MDSC communication. Depending on the agreement between client and provider, VN instantiate can imply different VN operations. There are two types of VN instantiation:
VN Instantiateは、VNの作成を要求するための顧客/アプリケーションからのアクションを指します。 VN Instantiateは、CNCからMDSCへの通信用です。クライアントとプロバイダー間の合意に応じて、VNインスタンス化は異なるVNオペレーションを意味する場合があります。 VNのインスタンス化には2つのタイプがあります。
VN Type 1: VN is viewed as a set of edge-to-edge links (VN members).
VNタイプ1：VNは一連のエッジ間リンク（VNメンバー）として表示されます。
VN Type 2: VN is viewed as a VN-topology comprising virtual nodes and virtual links.
VNタイプ2：VNは、仮想ノードと仮想リンクで構成されるVNトポロジとして表示されます。
Please see [RFC8453] for full details regarding the types of VN.
VNのタイプに関する詳細については、[RFC8453]を参照してください。
VN Modify refers to an action issued from customers/applications to modify an existing VN (i.e., an instantiated VN). VN Modify is for CNC-to-MDSC communication.
VN変更とは、既存のVN（つまり、インスタンス化されたVN）を変更するために顧客/アプリケーションから発行されるアクションを指します。 VN Modifyは、CNCからMDSCへの通信用です。
VN Modify, depending of the type of VN instantiated, can be:
インスタンス化されたVNのタイプに応じて、VN Modifyは次のいずれかになります。
1. a modification of the characteristics of VN members (edge-to-edge links) in the case of VN Type 1, or
1. VNタイプ1の場合のVNメンバー（エッジ間リンク）の特性の変更、または
2. a modification of an existing virtual topology (e.g., adding/ deleting virtual nodes/links) in the case of VN Type 2.
2. VNタイプ2の場合の既存の仮想トポロジの変更（仮想ノード/リンクの追加/削除など）
VN Delete refers to an action issued from customers/applications to delete an existing VN. VN Delete is for CNC-to-MDSC communication.
VN削除とは、既存のVNを削除するために顧客/アプリケーションから発行されるアクションを指します。 VN Deleteは、CNCからMDSCへの通信用です。
"VN Update" refers to any update to the VN that needs to be updated to the customers. VN Update is MDSC-to-CNC communication. VN Update fulfills a push model at the CMI level, making customers aware of any specific changes in the topology details related to the instantiated VN.
「VNアップデート」とは、お客様にアップデートする必要があるVNのアップデートを指します。 VN UpdateはMDSC-to-CNC通信です。 VN UpdateはCMIレベルでプッシュモデルを実行し、インスタンス化されたVNに関連するトポロジの詳細における特定の変更をお客様に通知します。
VN Update, depending of the type of VN instantiated, can be:
インスタンス化されたVNのタイプに応じて、VN Updateは次のいずれかになります。
1. an update of VN members (edge-to-edge links) in case of VN Type 1, or
1. VNタイプ1の場合のVNメンバー（エッジ間リンク）の更新、または
2. an update of virtual topology in case of VN Type 2.
2. VNタイプ2の場合の仮想トポロジの更新。
The connection-related information (e.g., Label Switched Paths (LSPs)) update association with VNs will be part of the "translation" function that happens in MDSC to map/translate VN request into TE semantics. This information will be provided in case the customer optionally wants to have more-detailed TE information associated with the instantiated VN.
VNとの接続関連情報（ラベルスイッチドパス（LSP）など）の更新の関連付けは、MDSCで発生する「変換」機能の一部となり、VN要求をTEセマンティクスにマップ/変換します。この情報は、インスタンス化されたVNに関連付けられたより詳細なTE情報が必要な場合に備えて提供されます。
VN Compute consists of a Request and Reply. "VN Compute Request" refers to an action from customers/applications to request a VN computation.
VN Computeはリクエストとリプライで構成されています。 「VN Compute Request」とは、VN計算を要求するための顧客/アプリケーションからのアクションを指します。
"VN Compute Reply" refers to the reply in response to VN Compute Request.
「VN Compute Reply」とは、VN Computeリクエストに対する応答のことです。
A VN Compute Request/Reply is to be differentiated from a VN Instantiate. The purpose of VN Compute is a priori exploration to compute network resources availability and getting a possible VN view in which path details can be specified matching customer/applications constraints. This a priori exploration may not guarantee the availability of the computed network resources at the time of instantiation.
VN Compute Request / Replyは、VNインスタンス化と区別されます。 VN Computeの目的は、ネットワークリソースの可用性を計算し、顧客/アプリケーションの制約に一致するパスの詳細を指定できる可能なVNビューを取得するアプリオリな調査です。この先験的な調査は、インスタンス化の時点で計算されたネットワークリソースの可用性を保証しない場合があります。
"VN Query" refers to an inquiry pertaining to a VN that has already been instantiated. VN Query fulfills a pull model that permits getting a topology view.
「VNクエリ」とは、すでにインスタンス化されているVNに関する問い合わせを指します。 VNクエリは、トポロジビューを取得できるプルモデルを満たします。
"VN Query Reply" refers to the reply in response to a VN Query. The topology view returned by a VN Query Reply would be consistent with the topology type instantiated for any specific VN.
「VNクエリ応答」とは、VNクエリに対する応答のことです。 VNクエリ応答によって返されるトポロジビューは、特定のVNに対してインスタンス化されたトポロジタイプと一致します。
This section provides a list of the main TE primitives necessary to satisfy ACTN requirements specified in [ACTN-REQ] related to typical TE operations supported at the MPI level.
このセクションでは、MPIレベルでサポートされる一般的なTE操作に関連する[ACTN-REQ]で指定されているACTN要件を満たすために必要な主要なTEプリミティブのリストを提供します。
The TE action primitives defined in this section should be supported at the MPI consistently with the type of topology defined at the CMI.
このセクションで定義されているTEアクションプリミティブは、CMIで定義されているトポロジのタイプと一貫してMPIでサポートされている必要があります。
The following TE action primitives are supported:
次のTEアクションプリミティブがサポートされています。
o TE Instantiate/Modify/Delete
o TEのインスタンス化/変更/削除
o TE Topology Update (see Section 4.4. for the description)
o TEトポロジー更新（説明はセクション4.4を参照）
o Path Compute
o パス計算
TE Action is an object describing the main TE primitives.
TEアクションは、主要なTEプリミティブを記述するオブジェクトです。
TE Action can assume one of the mentioned above primitives values.
TEアクションは、上記のプリミティブ値のいずれかを想定できます。
<TE Action> ::= <TE Instantiate> |
<TE Modify> |
<TE修正> |
<TE Delete> |
＜て でぇて＞ ｜
<TE Topology Update> |
<Path Compute> |
All these actions will solely happen at MPI level between MDSC and PNC.
これらすべてのアクションは、MDSCとPNC間のMPIレベルでのみ発生します。
"TE Instantiate" refers to an action issued from MDSC to PNC to instantiate new TE tunnels.
「TE Instantiate」とは、新しいTEトンネルをインスタンス化するためにMDSCからPNCに発行されるアクションを指します。
"TE Modify" refers to an action issued from MDSC to PNC to modify existing TE tunnels.
「TE変更」とは、既存のTEトンネルを変更するためにMDSCからPNCに発行されるアクションを指します。
"TE Delete" refers to an action issued from MDSC to PNC to delete existing TE tunnels.
「TE削除」とは、既存のTEトンネルを削除するためにMDSCからPNCに発行されるアクションを指します。
TE Topology Update is a primitive specifically related to MPI used to provide a TE resource update between any domain controller and MDSC regarding the entire content of any actual TE topology of a domain controller or an abstracted filtered view of TE topology depending on negotiated policy.
TEトポロジー更新は、ドメインコントローラーの実際のTEトポロジーの内容全体、またはネゴシエートされたポリシーに応じてTEトポロジーの抽象化されたフィルタービューに関して、ドメインコントローラーとMDSC間のTEリソース更新を提供するために使用されるMPIに特に関連するプリミティブです。
See [TE-TOPO] for detailed YANG implementation of TE topology update.
トポロジー更新の詳細なYANG実装については、[THE-TOP]を参照してください。
<TE Topology Update> ::= <TE-topology-list>
<TE-topology-list> ::= <TE-topology> [<TE-topology-list>]
<TE-topology> ::= [<Abstraction>] <TE-Topology-identifier> <Node-
list> <Link-list>
<Node-list> ::= <Node>[<Node-list>]
<Node> ::= <Node> <TE Termination Point-list>
<TE Termination Point-list> ::= <TE Termination Point> [<TE-
Termination Point-list>]
<Link-list> ::= <Link>[<Link-list>]
Where
ただし
Abstraction provides information on the level of abstraction (as determined a priori).
抽象化は、（演繹的に決定された）抽象化のレベルに関する情報を提供します。
TE-topology-identifier is an identifier that identifies a specific te-topology, e.g., te-types:te-topology-id [TE-TOPO].
TE-topology-identifierは、特定のte-topologyを識別する識別子です（例：te-types：te-topology-id [TE-TOPO]）。
Node-list is detailed information related to a specific node belonging to a te-topology, e.g., te-node-attributes [TE-TOPO].
ノードリストは、te-node-attributes [TE-TOPO]など、te-topologyに属する特定のノードに関連する詳細情報です。
Link-list is information related to the specific link related belonging to a te-topology, e.g., te-link-attributes [TE-TOPO].
リンクリストは、te-link-attributes [TE-TOPO]など、te-topologyに属する特定のリンクに関連する情報です。
TE Termination Point-list is detailed information associated with the termination points of a te-link related to a specific node, e.g., interface-switching-capability [TE-TOPO].
TEターミネーションポイントリストは、特定のノードに関連するte-linkのターミネーションポイントに関連する詳細情報です。たとえば、interface-switching-capability [TE-TOPO]です。
Path Compute consists of Request and Reply. "Path Compute Request" refers to an action from MDSC to PNC to request a path computation.
パスコンピューティングは、要求と応答で構成されます。 「経路計算要求」とは、経路計算を要求するためのMDSCからPNCへのアクションを指します。
"Path Compute Reply" refers to the reply in response to the Path Compute Request.
「パス計算応答」とは、パス計算要求に対する応答のことです。
The context of Path Compute is described in [Path-Compute].
Path Computeのコンテキストは、[Path-Compute]で説明されています。
This section provides a list of objects associated to VN action primitives.
このセクションでは、VNアクションプリミティブに関連付けられているオブジェクトのリストを示します。
A VN Identifier is a unique identifier of the VN.
VN IDは、VNの一意の識別子です。
VN Service Characteristics describes the customer/application requirements against the VNs to be instantiated.
VNサービスの特性は、インスタンス化されるVNに対する顧客/アプリケーションの要件を記述します。
<VN Service Characteristics> ::= <VN Connectivity Type>
<VN Directionality>
<VN方向性>
(<VN Traffic Matrix>...)
（<VNトラフィックマトリックス> ...）
<VN Survivability>
<VNサバイバビリティ>
Where
ただし
<VN Connectivity Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>|<Multi-
destination>
The Connectivity Type identifies the type of required VN Service. In addition to the classical types of services (e.g., P2P/P2MP, etc.), ACTN defines the "multi-destination" service that is a new P2P service where the endpoints are not fixed. They can be chosen among a list of preconfigured endpoints or dynamically provided by the CNC.
接続タイプは、必要なVNサービスのタイプを識別します。 ACTNは、従来のタイプのサービス（P2P / P2MPなど）に加えて、エンドポイントが固定されていない新しいP2Pサービスである「マルチ宛先」サービスを定義します。それらは、事前構成されたエンドポイントのリストから選択するか、CNCによって動的に提供できます。
VN Directionality indicates if a VN is unidirectional or bidirectional. This implies that each VN member that belongs to the VN has the same directionality as the VN.
VN方向性は、VNが単方向か双方向かを示します。これは、VNに属する各VNメンバーがVNと同じ方向性を持つことを意味します。
<VN Traffic Matrix> ::= <Bandwidth>
[<VN Constraints>]
[<VN制約>]
The VN Traffic Matrix represents the traffic matrix parameters for the required service connectivity. Bandwidth is a mandatory parameter, and a number of optional constraints can be specified in the VN Constraints (e.g., diversity, cost). They can include objective functions and TE metric bounds as specified in [RFC5541].
VNトラフィックマトリックスは、必要なサービス接続のトラフィックマトリックスパラメーターを表します。帯域幅は必須パラメーターであり、多数のオプションの制約をVN制約で指定できます（多様性、コストなど）。 [RFC5541]で指定されているように、目的関数とTEメトリック境界を含めることができます。
Further details on the VN constraints are specified below:
VN制約の詳細は次のとおりです。
<VN Constraints> ::= [<Layer Protocol>]
[<Diversity>]
( <Metric> | <VN Objective Function> )
Where:
ただし：
Layer Protocol identifies the layer topology at which the VN service is requested. It could be, for example, MPLS, Optical Data Unit (ODU), and Optical Channel (OCh).
レイヤプロトコルは、VNサービスが要求されるレイヤトポロジを識別します。たとえば、MPLS、光データユニット（ODU）、光チャネル（OCh）などです。
Diversity allows asking for diversity constraints for a VN Instantiate/Modify or a VN Path Compute. For example, a new VN or a path is requested in total diversity from an existing one (e.g., diversity exclusion).
多様性により、VNインスタンス化/変更またはVNパス計算の多様性制約を要求できます。たとえば、新しいVNまたはパスは、既存のVNからの完全な多様性で要求されます（たとえば、多様性の除外）。
<Diversity> ::= (<VN-exclusion> (<VN-id>...)) |
(<VN-Member-exclusion> (<VN-Member-id>...))
Metric can include all the Metrics (cost, delay, delay variation, latency) and bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471].
メトリックには、[RFC3630]および[RFC7471]によって定義および参照されるすべてのメトリック（コスト、遅延、遅延変動、レイテンシ）および帯域幅使用率パラメーターを含めることができます。
As for VN Objective Function, see Section 5.4.
VN目的関数については、5.4項を参照してください。
VN Survivability describes all attributes related to the VN recovery level and its survivability policy enforced by the customers/ applications.
VN存続可能性は、VNリカバリーレベルに関連するすべての属性と、顧客/アプリケーションによって適用されるその存続可能性ポリシーを記述します。
<VN Survivability> ::= <VN Recovery Level>
[<VN Tunnel Recovery Level>]
[<VNトンネル回復レベル>]
[<VN Survivability Policy>] Where:
[<VN存続可能性ポリシー>]場所：
VN Recovery Level is a value representing the requested level of resiliency required against the VN. The following values are defined:
VN回復レベルは、VNに必要な回復力の要求レベルを表す値です。以下の値が定義されています。
o Unprotected VN
o 保護されていないVN
o VN with per tunnel recovery: The recovery level is defined against the tunnels composing the VN, and it is specified in the VN Tunnel Recovery Level.
o トンネルごとのリカバリを使用するVN：リカバリレベルは、VNを構成するトンネルに対して定義され、VNトンネルリカバリレベルで指定されます。
<VN Tunnel Recovery Level> ::= <0:1>|<1+1>|<1:1>|<1:N>|<M:N>|
<On the fly restoration>
The VN Tunnel Recovery Level indicates the type of protection or restoration mechanism applied to the VN. It augments the recovery types defined in [RFC4427].
VNトンネル回復レベルは、VNに適用される保護または復元メカニズムのタイプを示します。 [RFC4427]で定義されている回復の種類を補強します。
<VN Survivability Policy> ::= [<Local Reroute Allowed>]
[<Domain Preference>]
[<ドメイン設定>]
[<Push Allowed>]
[<プッシュ許可>]
[<Incremental Update>]
[<増分更新>]
Where:
ただし：
Local Reroute Allowed is a delegation policy to the Server on whether or not to allow a local reroute fix upon a failure of the primary LSP.
Local Reroute Allowedは、プライマリLSPの障害時にローカルの再ルーティングの修正を許可するかどうかに関するサーバーへの委任ポリシーです。
Domain Preference is only applied on the MPI where the MDSC (client) provides a domain preference to each PNC (server), e.g., when an inter-domain link fails, then PNC can choose the alternative peering with this info.
ドメイン設定は、MDSC（クライアント）が各PNC（サーバー）にドメイン設定を提供するMPIにのみ適用されます。たとえば、ドメイン間リンクに障害が発生した場合、PNCはこの情報を使用して代替ピアリングを選択できます。
Push Allowed is a policy that allows a server to trigger an updated VN topology upon failure without an explicit request from the client. Push action can be set as default unless otherwise specified.
プッシュ許可は、クライアントからの明示的な要求なしに、サーバーが障害時に更新されたVNトポロジをトリガーできるようにするポリシーです。特に指定がない限り、プッシュアクションはデフォルトとして設定できます。
Incremental Update is another policy that triggers an incremental update from the server since the last period of update. Incremental update can be set as default unless otherwise specified.
増分更新は、最後の更新期間以降のサーバーからの増分更新をトリガーする別のポリシーです。特に指定がない限り、増分更新はデフォルトとして設定できます。
VN End-Point Object describes the VN's customer endpoint characteristics.
VNエンドポイントオブジェクトは、VNの顧客エンドポイント特性を記述します。
<VN End-Point> ::= (<Access Point Identifier>
[<Access Link Capability>] [<Source Indicator>])...
[<アクセスリンク機能>] [<ソースインジケータ>]）...
Where:
ただし：
Access Point Identifier represents a unique identifier of the client endpoint. They are used by the customer to ask for the setup of a virtual network instantiation. A VN End-Point is defined against each AP in the network and is shared between customer and provider. Both the customer and the provider will map it against their own physical resources.
アクセスポイント識別子は、クライアントエンドポイントの一意の識別子を表します。これらは、顧客が仮想ネットワークのインスタンス化のセットアップを要求するために使用されます。 VNエンドポイントは、ネットワーク内の各APに対して定義され、顧客とプロバイダーの間で共有されます。顧客とプロバイダーの両方が独自の物理リソースに対してそれをマッピングします。
Access Link Capability identifies the capabilities of the access link related to the given access point (e.g., max-bandwidth, bandwidth availability, etc.).
アクセスリンク機能は、特定のアクセスポイントに関連するアクセスリンクの機能（最大帯域幅、帯域幅の可用性など）を識別します。
Source Indicator indicates whether or not an endpoint is the source.
ソースインジケータは、エンドポイントがソースであるかどうかを示します。
The VN Objective Function applies to each VN member (i.e., each E2E tunnel) of a VN.
VN Objective Functionは、VNの各VNメンバー（つまり、各E2Eトンネル）に適用されます。
The VN Objective Function can reuse objective functions defined in Section 4 of [RFC5541].
VN目的関数は、[RFC5541]のセクション4で定義されている目的関数を再利用できます。
For a single path computation, the following objective functions are defined:
単一パスの計算では、次の目的関数が定義されています。
o MCP is the Minimum Cost Path with respect to a specific metric (e.g., shortest path).
o MCPは、特定のメトリック（最短パスなど）に関する最小コストパスです。
o MLP is the Minimum Load Path, meaning find a path composted by te-link least loaded.
o MLPは最小ロードパスです。つまり、te-linkによって構成されたパスが最小ロードであることがわかります。
o MBP is the Maximum residual Bandwidth Path.
o MBPは最大残余帯域幅パスです。
For a concurrent path computation, the following objective functions are defined:
並行パス計算では、次の目的関数が定義されています。
o MBC is to Minimize aggregate Bandwidth Consumption.
o MBCは、総帯域幅使用量を最小限に抑えることです。
o MLL is to Minimize the Load of the most loaded Link.
o MLLは、最もロードされたリンクのロードを最小化することです。
o MCC is to Minimize the Cumulative Cost of a set of paths.
o MCCは、一連のパスの累積コストを最小限に抑えることです。
VN Action Status is the status indicator whether or not the VN has been successfully instantiated, modified, or deleted in the server network in response to a particular VN action.
VNアクションステータスは、特定のVNアクションに応答して、サーバーネットワークでVNが正常にインスタンス化、変更、または削除されたかどうかを示すステータスインジケーターです。
Note that this action status object can be implicitly indicated and, thus, not included in any of the VN primitives discussed in Section 3.
このアクションステータスオブジェクトは暗黙的に示される可能性があるため、セクション3で説明するどのVNプリミティブにも含まれないことに注意してください。
When a VN is seen by the customer as a topology, it is referred to as "VN topology". This is associated with VN Type 2, which is composed of virtual nodes and virtual links.
お客様がVNをトポロジーと見なす場合、「VNトポロジー」と呼ばれます。これは、仮想ノードと仮想リンクで構成されるVN Type 2に関連付けられています。
<VN Topology> ::= <Virtual node list> <Virtual link list>
<Virtual node list> ::= <Virtual node> [<Virtual node list>]
<Virtual link list> :: = <Virtual link> [<Virtual link list>]
VN Member describes details of a VN Member that is a list of a set of VN Members represented as VN_Member_List.
VNメンバーは、VN_Member_Listとして表される一連のVNメンバーのリストであるVNメンバーの詳細を記述します。
<VN_Member_List> ::= <VN Member> [<VN_Member_List>]
Where <VN Member> ::= <Ingress VN End-Point>
[<VN Associated LSP>]
[<VN関連LSP>]
<Egress VN End-Point>
<下りVNエンドポイント>
Ingress VN End-Point is the VN End-Point information for the ingress portion of the AP. See Section 5.3 for VN End-Point details.
入力VNエンドポイントは、APの入力部分のVNエンドポイント情報です。 VNエンドポイントの詳細については、セクション5.3を参照してください。
Egress VN End-Point is the VN End-Point information for the egress portion of the AP. See Section 5.3 for VN End-Point details.
出力VNエンドポイントは、APの出力部分のVNエンドポイント情報です。 VNエンドポイントの詳細については、セクション5.3を参照してください。
VN Associated LSP describes the instantiated LSPs in the Provider's network for the VN Type 1. It describes the instantiated LSPs over the VN topology for VN Type 2.
VNに関連付けられたLSPは、VNタイプ1のプロバイダーのネットワークでインスタンス化されたLSPを記述します。これは、VNタイプ2のVNトポロジを介してインスタンス化されたLSPを記述します。
The VN Computed Path is the list of paths obtained after the VN path computation request from a higher controller. Note that the computed path is to be distinguished from the LSP. When the computed path is signaled in the network (and thus the resource is reserved for that path), it becomes an LSP.
VN計算パスは、上位のコントローラーからのVNパス計算要求の後に取得されたパスのリストです。計算されたパスはLSPと区別されることに注意してください。計算されたパスがネットワークでシグナリングされると（したがって、リソースはそのパス用に予約されます）、LSPになります。
<VN Computed Path> ::= (<Path>...)
This section provides the VN Service preference. VN Service is defined in Section 2.
このセクションでは、VNサービスの設定について説明します。 VNサービスはセクション2で定義されています。
<VN Service Preference> ::= [<Location Service Preference >]
[<Client-specific Preference >]
[<クライアント固有の設定>]
[<End-Point Dynamic Selection Preference >]
[<エンドポイントの動的選択設定>]
Where
ただし
Location Service Preference describes the End-Point Location's (e.g., data centers (DCs)) support for certain Virtual Network Functions (VNFs) (e.g., security function, firewall capability, etc.) and is used to find the path that satisfies the VNF constraint.
ロケーションサービス設定は、特定の仮想ネットワーク機能（VNF）（たとえば、セキュリティ機能、ファイアウォール機能など）に対するエンドポイントロケーション（たとえば、データセンター（DC））のサポートを記述し、VNFを満たすパスを見つけるために使用されます制約。
Client-specific Preference describes any preference related to VNS that an application/client can enforce via CNC towards lower-level controllers. For example, CNC can enforce client-specific preferences, e.g., selection of a destination DC from the set of candidate DCs based on some criteria in the context of Virtual Machine (VM) migration. MSDC/PNC should then provide the DC interconnection that supports the Client-specific Preference.
クライアント固有の設定は、アプリケーション/クライアントがCNCを介して下位レベルのコントローラーに強制できるVNSに関連する設定を記述します。たとえば、CNCは、クライアント固有の設定を適用できます。たとえば、仮想マシン（VM）の移行のコンテキストの基準に基づいて、候補DCのセットから宛先DCを選択できます。 MSDC / PNCは、クライアント固有の設定をサポートするDC相互接続を提供する必要があります。
End-Point Dynamic Selection Preference describes if the endpoint (e.g., DC) can support load-balancing, disaster recovery, or VM migration and so can be part of the selection by MDSC following service Preference enforcement by CNC.
エンドポイントの動的選択プリファレンスは、エンドポイント（DCなど）がロードバランシング、ディザスターリカバリー、またはVMの移行をサポートできるかどうかを示し、CNCによるサービスプリファレンスの施行に従ってMDSCによる選択の一部になることができます。
Tunnel Characteristics describes the parameters needed to configure TE tunnel.
トンネル特性では、TEトンネルの構成に必要なパラメータについて説明します。
<TE Tunnel Characteristics> ::= [<Tunnel Type>]
<Tunnel Id>
<トンネルID>
[<Tunnel Layer>]
[<トンネルレイヤー>]
[<Tunnel end-point>]
[<トンネルエンドポイント>]
[<Tunnel protection-restoration>]
[<トンネル保護-復元>]
<Tunnel Constraints>
<トンネル制約>
[<Tunnel Optimization>]
[<トンネル最適化>]
Where
ただし
<Tunnel Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>
The Tunnel Type identifies the type of required tunnel. In this document, only the P2P model is provided.
トンネルタイプは、必要なトンネルのタイプを識別します。このドキュメントでは、P2Pモデルのみが提供されています。
Tunnel Id is the TE tunnel identifier
トンネルIDはTEトンネル識別子です
Tunnel Layer represents the layer technology of the LSPs supporting the tunnel
トンネルレイヤは、トンネルをサポートするLSPのレイヤテクノロジーを表します
<Tunnel End Points> ::= <Source> <Destination>
<Tunnel protection-restoration> ::= <prot 0:1>|<prot 1+1>|<prot
1:1>|<prot 1:N>|prot <M:N>|<restoration>
Tunnel Constraints are the base tunnel configuration constraints
parameters.
Where <Tunnel Constraints> ::= [<Topology Id>]
[<Bandwidth>]
[<帯域幅>]
[<Disjointness>]
[<素性>]
[<SRLG>]
[<SRLG>]
[<Priority>]
[<優先度>]
[<Affinities>]
[<アフィニティ>]
[<Tunnel Optimization>]
[<トンネル最適化>]
[<Objective Function>]
[<目的関数>]
Topology Id references the topology used to compute the tunnel path.
トポロジIDは、トンネルパスの計算に使用されるトポロジを参照します。
Bandwidth is the bandwidth used as a parameter in path computation.
帯域幅は、パス計算のパラメータとして使用される帯域幅です。
<Disjointness> ::= <node> | <link> | <srlg>
Disjointness provides the type of resources from which the tunnel has to be disjointed.
Disjointnessは、トンネルを分離する必要があるリソースのタイプを提供します。
Shared Risk Link Group (SRLG) is a group of physical resources impacted by the same risk from which an E2E tunnel is required to be disjointed.
共有リスクリンクグループ（SRLG）は、E2Eトンネルを分離する必要があるのと同じリスクの影響を受ける物理リソースのグループです。
<Priority> ::= <Holding Priority> <Setup Priority>
where
ただし
Setup Priority indicates the level of priority for taking resources from another tunnel [RFC3209].
Setup Priorityは、別のトンネルからリソースを取得するための優先度のレベルを示します[RFC3209]。
Holding Priority indicates the level of priority to hold resources avoiding preemption from another tunnel [RFC3209].
保持優先度は、別のトンネルからのプリエンプションを回避するリソースを保持する優先度のレベルを示します[RFC3209]。
Affinities represents the structure to validate a link belonging to the path of the tunnel [RFC3209].
アフィニティは、トンネルのパス[RFC3209]に属するリンクを検証するための構造を表します。
<Tunnel Optimization> ::= <Metric> | <Objective Function>
Metric can include all the Metrics (cost, delay, delay variation, latency) and bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471].
メトリックには、[RFC3630]および[RFC7471]によって定義および参照されるすべてのメトリック（コスト、遅延、遅延変動、レイテンシ）および帯域幅使用率パラメーターを含めることができます。
<Objective Function> ::= <objective function type>
<objective function type> ::= <MCP> | <MLP> | <MBP> | <MBC> | <MLL>
| <MCC>
See Section 5.4 for a description of objective function type.
目的関数タイプの説明については、セクション5.4を参照してください。
This section describes the mapping of VN primitives with VN Objects based on Section 5.
このセクションでは、セクション5に基づいて、VNプリミティブとVNオブジェクトのマッピングについて説明します。
<VN Instantiate> ::= <VN Service Characteristics>
<VN Member-List>
<VNメンバーリスト>
[<VN Service Preference>]
[<VNサービス設定>]
[<VN Topology>]
[<VNトポロジ>]
<VN Modify> ::= <VN identifier>
<VN Service Characteristics>
<VN Service Characteristics>
<VN Member-List>
<VNメンバーリスト>
[<VN Service Preference>]
[<VNサービス設定>]
[<VN Topology>]
[<VNトポロジ>]
<VN Delete> ::= <VN Identifier>
<VN Update> :: = <VN Identifier>
[<VN Member-List>]
[<VN Topology>]
[<VNトポロジ>]
<VN Path Compute Request> ::= <VN Service Characteristics>
<VN Member-List>
<VNメンバーリスト>
[<VN Service Preference>]
[<VNサービス設定>]
<VN Path Compute Reply> ::= <VN Computed Path>
<VN Query> ::= <VN Identifier>
<VN Query Reply> ::= <VN Identifier>
<VN Associated LSP>
<VN関連LSP>
[<TE Topology Reference>]
[<TEトポロジリファレンス>]
This section describes the mapping of TE primitives with TE Objects based on Section 6.
このセクションでは、セクション6に基づいて、TEプリミティブとTEオブジェクトのマッピングについて説明します。
<TE Instantiate> ::= <TE Tunnel Characteristics>
<TE Modify> ::= <TE Tunnel Characteristics>
<TE Delete> ::= <Tunnel Id>
<TE Topology Update> ::= <TE-topology-list>
<Path Compute Request> ::= <TE Tunnel Characteristics>
<Path Compute Reply> ::= <TE Computed Path>
<TE Tunnel Characteristics>
<TE Tunnel Characteristics>
The ACTN information model is not directly relevant when considering potential security issues. Rather, it defines a set of interfaces for TE networks. The underlying protocols, procedures, and implementations used to exchange the information model described in this document will need to secure the request and control of resources with proper authentication and authorization mechanisms. In addition, the data exchanged over the ACTN interfaces discussed in this document requires verification of data integrity. Backup or redundancies should also be available to restore the affected data to its correct state.
潜在的なセキュリティ問題を検討する場合、ACTN情報モデルは直接関係ありません。むしろ、TEネットワークの一連のインターフェースを定義します。このドキュメントで説明されている情報モデルを交換するために使用される基本的なプロトコル、手順、および実装は、適切な認証および承認メカニズムでリソースの要求と制御を保護する必要があります。さらに、このドキュメントで説明されているACTNインターフェイスを介して交換されるデータには、データの整合性の検証が必要です。影響を受けるデータを正しい状態に復元するには、バックアップまたは冗長性も利用できる必要があります。
Implementations of the ACTN framework will have distributed functional components that will exchange an instantiation that adheres to this information model. Implementations should encrypt data that flows between them, especially when they are implemented at remote nodes and irrespective of whether these data flows are on external or internal network interfaces. The information model may contain customer, application, and network data that, for business or privacy reasons, may be considered sensitive. It should be stored only in an encrypted data store.
ACTNフレームワークの実装には、この情報モデルに準拠したインスタンス化を交換する分散機能コンポーネントがあります。特にリモートノードに実装されている場合、これらのデータフローが外部または内部ネットワークインターフェイス上にあるかどうかに関係なく、実装はそれらの間を流れるデータを暗号化する必要があります。情報モデルには、ビジネスまたはプライバシー上の理由から機密と見なされる可能性のある顧客、アプリケーション、およびネットワークデータが含まれる場合があります。暗号化されたデータストアにのみ保存する必要があります。
The ACTN security discussion is further split into two specific interfaces:
ACTNセキュリティの説明は、さらに2つの特定のインターフェイスに分かれています。
o Interface between the CNC and MDSC, CNC-MDSC Interface (CMI)
o CNCとMDSC間のインターフェース、CNC-MDSCインターフェース（CMI）
o Interface between the MDSC and PNC, MDSC-PNC Interface (MPI).
o MDSCとPNC間のインターフェイス、MDSC-PNCインターフェイス（MPI）。
See the detailed discussion of the CMI and MPI in Sections 9.1 and 9.2 (respectively) in [RFC8453].
[RFC8453]のセクション9.1および9.2（それぞれ）のCMIおよびMPIの詳細な説明を参照してください。
The conclusion is that all data models and protocols used to realize the ACTN information model should have rich security features, as discussed in this section. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific.
このセクションで説明するように、ACTN情報モデルを実現するために使用されるすべてのデータモデルとプロトコルには、豊富なセキュリティ機能が必要です。追加のセキュリティリスクがまだ存在する可能性があります。したがって、特定のセキュリティ機能とプロトコルの説明と適用性は、使用例と環境に固有のドキュメントでより適切に説明されます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
[RFC8453] Ceccarelli、D.、Ed。 Y.リー、編、「TEネットワークの抽象化と制御のフレームワーク（ACTN）」、RFC 8453、DOI 10.17487 / RFC8453、2018年8月、<https://www.rfc-editor.org/info/rfc8453> 。
[ACTN-REQ] Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. Lee, "Requirements for Abstraction and Control of TE Networks", Work in Progress, draft-ietf-teas-actn-requirements-09, March 2018.
[ACTN-REQ] Lee、Y.、Ceccarelli、D。、宮坂、T.、Shin、J。、およびK. Lee、「TEネットワークの抽象化と制御の要件」、Work in Progress、draft-ietf-teas -actn-requirements-09、2018年3月。
[Path-Compute] Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma, A., Shi, Y., Vilata, R., and K. Sethuraman, "Yang model for requesting Path Computation", Work in Progress, draft-ietf-teas-yang-path-computation-02, June 2018.
[Path-Compute] Busi、I.、Belotti、S.、Lopezalvarez、V.、Dios、O.、Sharma、A.、Shi、Y.、Vilata、R。、およびK. Sethuraman、「リクエストするためのヤンモデルパス計算」、進行中の作業、draft-ietf-teas-yang-path-computation-02、2018年6月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-editor.org/info/rfc4427>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-editor.org/info/rfc4427>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.
[RFC5541] Le Roux、JL。、Vasseur、JP。、and Y. Lee、 "Encoding of Objective Functions in the Path Computation Element Communication Protocol（PCEP）"、RFC 5541、DOI 10.17487 / RFC5541、June 2009、<https： //www.rfc-editor.org/info/rfc5541>。
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.
[RFC7471] Giacalone、S.、Ward、D.、Drake、J.、Atlas、A。、およびS. Previdi、「OSPF Traffic Engineering（TE）Metric Extensions」、RFC 7471、DOI 10.17487 / RFC7471、2015年3月、 <https://www.rfc-editor.org/info/rfc7471>。
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, <https://www.rfc-editor.org/info/rfc7926>.
[RFC7926] Farrel、A.、Ed。、Drake、J.、Bitar、N.、Swallow、G.、Ceccarelli、D。、およびX. Zhang、「相互接続されたトラフィックエンジニアリングネットワーク間の情報交換のための問題ステートメントとアーキテクチャ"、BCP 206、RFC 7926、DOI 10.17487 / RFC7926、2016年7月、<https://www.rfc-editor.org/info/rfc7926>。
[TE-TOPO] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", Work in Progress, draft-ietf-teas-yang-te-topo-18, June 2018.
[TE-TOPO] Liu、X.、Bryskin、I.、Beeram、V.、Saad、T.、Shah、H.、O。Dios、「YANG Data Model for Traffic Engineering（TE）Topologies」、Work in進捗状況、ドラフトieetf-teas-yang-te-topo-18、2018年6月。
Contributors
貢献者
Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com
Zは非常にGHです。UAはテクノロジーのメールです。sleep@ just.comだけです。
Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com
X Ian Zhang hu Aは技術メールです：Zhang。Xian @ Huawei.com
Authors' Addresses
著者のアドレス
Young Lee (Editor) Huawei Technologies 5340 Legacy Drive Plano, TX 75023, USA
Young Lee（編集者）Huawei Technologies 5340 Legacy Drive Plano、TX 75023、USA
Phone: (469)277-5838 Email: leeyoung@huawei.com
電話：(469)277-5838メール：leeyoung@huawei.com
Sergio Belotti (Editor) Nokia Via Trento, 30 Vimercate, Italy
Sergio Belotti（編集者）Nokia Via Trento、30 Vimercate、イタリア
Email: sergio.belotti@nokia.com
Dhruv Dhody Huawei Technologies, Divyashree Technopark, Whitefield Bangalore, India
Dhruv Dhodi Huawei Technologies、Divyashree Technopark、Whitfield Bangalore、インド
Email: dhruv.ietf@gmail.com
Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden
Daniele Ceccarelli Ericsson Torshamnsgatan、48ストックホルム、スウェーデン
Email: daniele.ceccarelli@ericsson.com
Bin Yeong Yoon ETRI
ビン・ヨンユンETRI
Email: byyun@etri.re.kr