Internet Engineering Task Force (IETF) Y. Lee, Ed.
Request for Comments: 9731 Samsung Electronics
Category: Standards Track D. Dhody, Ed.
ISSN: 2070-1721 Huawei
D. Ceccarelli
Cisco
I. Bryskin
Individual
B. Yoon
ETRI
March 2025
A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it were a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework (RFC 8453).
仮想ネットワーク（VN）は、顧客が顧客に提供するサービスプロバイダーによって提供されるネットワークであり、顧客が物理的なネットワークであるかのように必要な方法で使用します。このドキュメントは、一般にVN操作のモードに適用できるYangデータモデルを提供します。これには、TEネットワーク（ACTN）フレームワーク（RFC 8453）の抽象化と制御に従ってVN操作が含まれます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9731.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9731で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology and Conventions
1.2. Tree Diagram
1.3. Prefixes in Data Node Names
2. Use Case of VN YANG Data Model in the ACTN Context
2.1. Type 1 VN
2.2. Type 2 VN
3. High-Level Control Flows with Examples
3.1. Type 1 VN Illustration
3.2. Type 2 VN Illustration
3.2.1. VN and AP Usage
4. VN YANG Data Model Usage
4.1. Customer View of VN
4.2. Auto-creation of VN by MDSC
4.3. Innovative Services
4.3.1. VN Compute
4.3.2. Multiple Sources and Multiple Destinations
4.4. Others
4.5. Summary
5. VN YANG Data Model (Tree Structure)
6. VN YANG Data Model
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Performance Constraints
Appendix B. JSON Example
B.1. VN JSON
B.2. TE Topology JSON
Acknowledgments
Contributors
Authors' Addresses
Abstraction and Control of TE Networks (ACTN) describes a set of management and control functions used to operate one or more Traffic Engineered (TE) networks to construct a Virtual Network (VN). A VN is represented to customers and is built from the abstractions of the underlying TE networks [RFC8453]. This document provides a YANG data model [RFC7950] generally applicable to any mode of VN operation. ACTN is the primary example of the usage of the VN YANG data model, but VN is not limited to it.
TEネットワークの抽象化と制御（ACTN）は、仮想ネットワーク（VN）を構築するために1つ以上のトラフィックエンジニアリング（TE）ネットワークを操作するために使用される一連の管理および制御機能について説明します。VNは顧客に表され、基礎となるTEネットワークの抽象化から構築されています[RFC8453]。このドキュメントは、一般にVN操作のモードに一般的に適用できるYangデータモデル[RFC7950]を提供します。Actnは、VN Yangデータモデルの使用の主要な例ですが、VNはそれに限定されません。
The VN model defined in this document is applicable in a generic sense as an independent model in and of itself. It can also work together with other customer service models such as the L3VPN Service Model (L3SM) [RFC8299], the L2VPN Service Model (L2SM) [RFC8466], and the L1 Connectivity Service Model (L1CSM) [L1CSM-YANG] to provide complete life-cycle service management and operations.
このドキュメントで定義されているVNモデルは、それ自体が独立したモデルとして一般的な意味で適用されます。また、L3VPNサービスモデル（L3SM）[RFC8299]、L2VPNサービスモデル（L2SM）[RFC8466]、L1接続サービスモデル（L1CSM）[L1CSM-YANG]などの他のカスタマーサービスモデルと協力して、ライフサイクルサービス管理と運用を提供します。
The YANG data model discussed in this document basically provides the following:
このドキュメントで説明されているYangデータモデルは、基本的に以下を提供します。
* Characteristics of Access Points (APs) that describe customer's endpoint characteristics;
* 顧客のエンドポイント特性を説明するアクセスポイント（AP）の特性。
* Characteristics of Virtual Network Access Points (VNAPs) that describe how an AP is partitioned for multiple VNs sharing the AP and its reference to a Link Termination Point (LTP) of the Provider Edge (PE) node;
* APを共有する複数のVNとプロバイダーEdge（PE）ノードのリンク終端ポイント（LTP）への基準を共有する複数のVNに対してAPがどのように分割されるかを説明する仮想ネットワークアクセスポイント（VNAP）の特性。
* Characteristics of VNs that describe the customer's VN in terms of multiple VN members comprising a VN, multi-source and/or multi-destination characteristics of the VN member, the VN's reference to TE-topology's abstract node.
* VN、マルチソース、および/またはVNメンバーのマルチ設定特性を含む複数のVNメンバーの観点から顧客のVNを記述するVNの特性、VNのTE-Topologyの抽象ノードへの言及。
An abstract TE topology is a topology that contains abstract topological elements (nodes, links) created and customized based on customer preference [RFC8795]. The actual VN instantiation and computation is performed with connectivity matrices of the TE Topology model [RFC8795], which provides a TE network topology abstraction and management operation. As per [RFC8795], a TE node connectivity matrix is the TE node's switching limitations in the form of valid switching combinations of the TE node's LTPs and potential TE paths. The VN representation relies on a single abstract TE node with a connectivity matrix. The VN can be abstracted as a set of edge-to-edge links (a Type 1 VN). Each link is the VN member that is mapped to the connectivity matrix entry (Section 2.1). The VN can also be abstracted as a topology of virtual nodes and virtual links (a Type 2 VN). Alongside the mapping of VN members to a connectivity matrix entry, an underlay path can also be specified (Section 2.2).
抽象的なTEトポロジは、顧客の好みに基づいて作成およびカスタマイズされた抽象的なトポロジ要素（ノード、リンク）を含むトポロジーです[RFC8795]。実際のVNインスタンス化と計算は、TEトポロジモデル[RFC8795]の接続マトリックスで実行され、TEネットワークトポロジの抽象化と管理操作を提供します。[RFC8795]によると、TEノード接続マトリックスは、TEノードのLTPと潜在的なTEパスの有効なスイッチング組み合わせの形式でのTEノードの切り替え制限です。VN表現は、接続マトリックスを備えた単一の抽象TEノードに依存しています。VNは、エッジとエッジへのリンクのセット（タイプ1 VN）として抽出できます。各リンクは、接続マトリックスエントリ（セクション2.1）にマッピングされるVNメンバーです。VNは、仮想ノードと仮想リンク（タイプ2 VN）のトポロジとして抽象化することもできます。接続マトリックスエントリへのVNメンバーのマッピングに加えて、アンダーレイパスも指定できます（セクション2.2）。
Once the TE Topology model is used in triggering VN instantiation over the networks, the TE model [YANG-TE] will inevitably interact with the TE Topology model when setting up actual tunnels and Label Switched Paths (LSPs) under the tunnels.
TEトポロジモデルがネットワーク上のVNインスタンス化のトリガーに使用されると、TEモデル[Yang-TE]は、実際のトンネルをセットアップし、トンネルの下でスイッチされたパス（LSP）をラベル付けするときにTEトポロジモデルと必然的に相互作用します。
Sections 2 and 3 provide a discussion of how the VN YANG data model is applicable to the ACTN context where a Virtual Network Service (VNS) operation is implemented for the interface of the Customer Network Controller (CNC) and the Multi-Domain Service Coordinator (MDSC).
セクション2および3では、VN Yangデータモデルが、カスタマーネットワークコントローラー（CNC）とマルチドメインサービスコーディネーター（MDSC）のインターフェイスに仮想ネットワークサービス（VNS）操作が実装されるACTNコンテキストにどのように適用できるかについての議論を示します。
The YANG data model for the CNC-MDSC Interface (CMI) is also known as the "customer service model" in [RFC8309]. The YANG data model discussed in this document is used to operate customer-driven VNs during the VN instantiation and computation as well as its life-cycle service management and operations.
CNC-MDSCインターフェイス（CMI）のYangデータモデルは、[RFC8309]の「カスタマーサービスモデル」としても知られています。このドキュメントで説明されているYangデータモデルは、VNインスタンス化と計算中に顧客主導のVNSを操作するために使用されます。
The VN operational state is included in the same tree as the configuration consistent with Network Management Datastore Architecture (NMDA) [RFC8342].
VNの動作状態は、ネットワーク管理データストアアーキテクチャ（NMDA）[RFC8342]と一致する構成と同じツリーに含まれています。
This document borrows the following abbreviations from [RFC8453] and/ or [RFC8795]:
この文書は、[RFC8453]および/または[RFC8795]から次の略語を借用しています。
VN:
VN:
Virtual Network
仮想ネットワーク
AP:
AP:
Access Point
アクセスポイント
VNAP:
VNAP：
VN Access Point
VNアクセスポイント
ACTN:
Actn：
Abstraction and Control of TE Networks
TEネットワークの抽象化と制御
CNC:
CNC:
Customer Network Controller
カスタマーネットワークコントローラー
MDSC:
MDSC：
Multi-Domain Service Coordinator
マルチドメインサービスコーディネーター
CMI:
CMI:
CNC-MDSC Interface
CNC-MDSCインターフェイス
LTP:
LTP:
Link Termination Point
リンク終端ポイント
This document borrows the terminology in Section 1.1 of [RFC7926], the term "Service Model" from [RFC8309], and the term "Connectivity Matrix" from [RFC8795].
このドキュメントは、[RFC7926]のセクション1.1のセクション1.1、[RFC8309]の「サービスモデル」という用語、[RFC8795]の「接続マトリックス」という用語の用語を借用しています。
Various examples in this document contain long lines that may be folded, as described in [RFC8792].
このドキュメントのさまざまな例には、[RFC8792]で説明されているように、折り畳まれる可能性のある長い行が含まれています。
A simplified graphical representation of the data model is used in Section 5 of this document. The meaning of the symbols in these diagrams is defined in [RFC8340].
このドキュメントのセクション5では、データモデルの簡略化されたグラフィカルな表現が使用されています。これらの図のシンボルの意味は、[RFC8340]で定義されています。
In this document, the names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules as shown in Table 1.
このドキュメントでは、データノードとその他のデータモデルオブジェクトの名前は、表1に示すように、対応するYangインポートモジュールに関連付けられた標準プレフィックスを使用してプレフィックスされます。
+==========+=======================+===========+
| Prefix | YANG Module | Reference |
+==========+=======================+===========+
| vn | ietf-vn | RFC 9731 |
+----------+-----------------------+-----------+
| yang | ietf-yang-types | [RFC6991] |
+----------+-----------------------+-----------+
| nw | ietf-network | [RFC8345] |
+----------+-----------------------+-----------+
| nt | ietf-network-topology | [RFC8345] |
+----------+-----------------------+-----------+
| te-types | ietf-te-types | [RFC8776] |
+----------+-----------------------+-----------+
| tet | ietf-te-topology | [RFC8795] |
+----------+-----------------------+-----------+
Table 1: Prefixes and Corresponding YANG Modules
表1：プレフィックスと対応するヤンモジュール
In this section, ACTN is being used to illustrate the general usage of the VN YANG data model. The model presented in this section has the following ACTN context.
このセクションでは、ACTNはVN Yangデータモデルの一般的な使用法を説明するために使用されています。このセクションで示されているモデルには、次のACTNコンテキストがあります。
+-------+
| CNC |
+-------+
|
| VN + TE Topology
|
+-----------------------+
| MDSC |
+-----------------------+
Figure 1: ACTN CMI
図1：ACTN CMI
Both ACTN VN and TE Topology YANG data models are used over the CMI to establish a VN over TE networks, as shown in Figure 1.
図1に示すように、ACTN VNおよびTEトポロジーヤンデータモデルの両方がCMIを介して使用されてVNをTEネットワーク上に確立します。
As defined in [RFC8453], a VN is a customer view of the TE network. To recapitulate VN types from [RFC8453], a Type 1 VN is defined as follows:
[RFC8453]で定義されているように、VNはTEネットワークの顧客ビューです。[RFC8453]からVNタイプを要約するために、タイプ1 VNは次のように定義されます。
The VN can be seen as a set of edge-to-edge abstract links (a Type 1 VN). Each abstract link is referred to as a VN member and is formed as an end-to-end tunnel across the underlying networks. Such tunnels may be constructed by recursive slicing or abstraction of paths in the underlying networks and can encompass edge points of the customer's network, access links, intra-domain paths, and inter-domain links.
VNは、エッジからエッジへの抽象リンクのセット（タイプ1 VN）と見なすことができます。各抽象リンクはVNメンバーと呼ばれ、基礎となるネットワーク全体のエンドツーエンドトンネルとして形成されます。このようなトンネルは、基礎となるネットワーク内のパスの再帰スライスまたは抽象化によって構築され、顧客のネットワーク、アクセスリンク、ドメイン内パス、およびドメイン間リンクのエッジポイントを包含できます。
If we were to create a VN where we have four VN members as follows:
次のように4人のVNメンバーがいるVNを作成する場合：
VN member 1 L1-L4
VN member 2 L1-L7
VN member 3 L2-L4
VN member 4 L3-L8
Figure 2: VN Members (Type 1 VN)
図2：VNメンバー（タイプ1 VN）
Where L1, L2, L3, L4, L7, and L8 correspond to a Customer Endpoint (or AP).
ここで、L1、L2、L3、L4、L7、およびL8は、顧客エンドポイント（またはAP）に対応しています。
This VN can be modeled as one abstract node representation as follows in Figure 3:
このVNは、図3の次のように、1つの要約ノード表現としてモデル化できます。
+----------------------------------------------+
| |
L1----|..............................................|------L4
| . . |
| . AN1 . |
| . . |
| ..................................*.....|------L7
| . |
L2-----|....................................... |
| |
L3-----|..............................................|------L8
| |
+----------------------------------------------+
Figure 3: Abstract Node (Type 1 Topology)
図3：要約ノード（タイプ1トポロジ）
Modeling a VN as one abstract node is the easiest way for customers to express their end-to-end connectivity as shown in Figure 3.
VNを1つの抽象ノードとしてモデリングすることは、図3に示すように、顧客がエンドツーエンドの接続を表現する最も簡単な方法です。
For some VN members, the customers are allowed to configure the intended path. To achieve this, alongside the single node abstract topology, an underlay topology is also needed. The underlay topology could be native TE topology or an abstract TE topology. The intended path is set based on the nodes and links of the underlay topology. A Type 1 VN can be viewed as a higher-level abstraction of a Type 2 VN, which represents a single node abstract topology over the underlay topology and includes a mechanism to specify intended paths. These topologies could be mutually agreed upon between the CNC and the MDSC prior to VN creation or they could be created as part of VN instantiation.
一部のVNメンバーの場合、顧客は意図したパスを構成することができます。これを実現するには、単一のノードの抽象トポロジーとともに、アンダーレイトポロジも必要です。アンダーレイトポロジーは、ネイティブTEトポロジーまたは抽象的なTEトポロジである可能性があります。意図したパスは、アンダーレイトポロジのノードとリンクに基づいて設定されます。タイプ1 VNは、タイプ2 VNの高レベルの抽象化と見なすことができます。これは、アンダーレイトポロジに対する単一のノード抽象トポロジを表し、意図したパスを指定するメカニズムを含む。これらのトポロジは、VN作成の前にCNCとMDSCの間で相互に合意することも、VNインスタンス化の一部として作成することもできます。
If a Type 2 VN is desired for some or all of the VN members of a Type 1 VN (see the example in Section 2.1), the TE Topology model can provide the following abstract topologies (a single node topology AN1 and an underlay topology (with nodes S1 to S11 and corresponding links)).
タイプ2 VNの一部またはすべてのVNメンバーにタイプ2 VNが望まれている場合（セクション2.1の例を参照）、TEトポロジモデルは次の抽象トポロジ（単一のノードトポロジAN1およびアンダーレイトポロジ（ノードS1からS11および対応するリンクを使用）を提供できます。
+----------------------------------------------+
| S1 S2 |
| O...............O |
| ......... ....... . |
| . . . |
|S3 . . S4 . S5 |
L1----|.O......................O.........O...........|------L4
| . . . |
| . . . |
| . S6 . S7 . S8 |
| O ................O.........O.......|------L7
| . . . . ..... |
|S9 . . .S10 . . |
L2-----|...O.....O.....................O..............|------L8
| . S11 |
L3-----|.. |
| AN1 |
+----------------------------------------------+
Figure 4: Type 2 Topology
図4：タイプ2トポロジー
As shown in Figure 4, the abstract node is AN1 and an underlay topology is depicted with nodes and links (S1 to S11).
図4に示すように、要約ノードはAN1であり、アンダーレイトポロジはノードとリンク（S1〜S11）で描かれています。
As an example, if VN member 1 (L1-L4) is chosen to configure its own path over Type 2 topology, it can select, say, a path that consists of the explicit path {S3,S4,S5} based on the underlay topology and its service requirement. This capability is enacted via TE-topology configuration by the customer.
例として、VNメンバー1（L1-L4）がタイプ2トポロジに対する独自のパスを構成するために選択された場合、たとえば、アンダーレイトポロジとそのサービス要件に基づいて明示的なパス{S3、S4、S5}で構成されるパスを選択できます。この機能は、顧客によるTEトポロジー構成によって制定されます。
If this VN is Type 1, the following diagram shows the message flow between CNC and MDSC to instantiate this VN using VN and TE Topology YANG data models.
このVNがタイプ1の場合、次の図は、CNCとMDSCの間のメッセージの流れを示しており、VNとTEトポロジーYangデータモデルを使用してこのVNをインスタンス化します。
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE Topo | POST /nw:networks/nw:network/ |
model (w/ Conn. | nw:node/te-node-id/ |
Matrix on one | tet:connectivity-matrices/ |
abstract node) | tet:connectivity-matrix |
|-------------------------------->|
| HTTP 200 |
|<--------------------------------|
| |
CNC POST the | POST /virtual-network |
VN identifying |-------------------------------->| If there is
AP, VNAP, and VN | | multi-src/dest,
members and maps | | then MDSC
to the TE Topo | HTTP 200 | selects an
model |<--------------------------------| src or dest
| | and updates
| | VN YANG
CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status: |
| selected VN members |
| in case of multi-s/d) |
|<--------------------------------|
| |
Figure 5: Type 1 VN Illustration
図5：タイプ1 VNイラスト
For some VN members, the customer may want to "configure" an explicit path that connects its two endpoints. Let us consider the following example:
一部のVNメンバーの場合、顧客は2つのエンドポイントを接続する明示的なパスを「構成」したい場合があります。次の例を考えてみましょう。
VN member 1 L1-L4 (via S3, S4, and S5)
VN member 2 L1-L7 (via S3, S4, S7, and S8)
VN member 3 L2-L7 (via S9, S10, and S11)
VN member 4 L3-L8 (via S9, S10, and S11)
Figure 6: VN Members (Type 2 VN)
図6：VNメンバー（タイプ2 VN）
There are two options depending on whether CNC or MDSC creates the single abstract node topology.
CNCまたはMDSCが単一の抽象ノードトポロジを作成するかどうかに応じて、2つのオプションがあります。
Case 1:
ケース1：
If the CNC creates the single abstract node topology, the message flow between the CNC and MDSC to instantiate this VN using a VN and TE Topology YANG data model would be as shown in the following diagram:
CNCが単一の抽象ノードトポロジを作成すると、VNとTEトポロジーYangデータモデルを使用してこのVNをインスタンス化するためのCNCとMDSCの間のメッセージの流れは、次の図に示されています。
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE Topo | POST /nw:networks/nw:network/ |
model (w/ Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix |
abstract node and|---------------------------------------->|
explicit paths in| |
the Conn. Matrix)| HTTP 200 |
|<----------------------------------------|
| |
CNC POST the | POST /virtual-network |
VN identifying |---------------------------------------->|
AP, VNAP, and VN | |
members and maps | |
to the TE Topo | HTTP 200 |
model |<----------------------------------------|
| |
| |
CNC GET the | GET /virtual-network |
VN YANG status |---------------------------------------->|
| |
| HTTP 200 (VN with status) |
|<----------------------------------------|
| |
Figure 7: Type 2 VN Illustration: Case 1
図7：タイプ2 VN図：ケース1
Case 2:
ケース2：
On the other hand, if MDSC create the single abstract node topology based on VN YANG posted by the CNC, the following diagram shows the message flow between CNC and MDSC to instantiate this VN using VN and TE Topology YANG data models.
一方、MDSCがCNCによって投稿されたVN Yangに基づいて単一の要約ノードトポロジを作成する場合、次の図は、VNとTEトポロジーYangデータモデルを使用してこのVNをインスタンス化するためのCNCとMDSCの間のメッセージの流れを示しています。
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST VN | |
identifying AP, | |
VNAP and VN | POST /virtual-network | MDSC populates
members |-------------------------------->| a single abst.
| HTTP 200 | node topology
|<--------------------------------| by itself
| |
CNC GET VN & | GET /virtual-network & |
POST TE Topo | POST /nw:networks/nw:network/ |
models (w/ | nw:node/te-node-id/tet: |
Conn. Matrix | connectivity-matrices/ |
on the | tet:connectivity-matrix |
abstract node |-------------------------------->|
and explicit | |
paths in the | |
Conn. Matrix) | |
| HTTP 200 |
|<--------------------------------|
| |
| |
CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status) |
|<--------------------------------|
| |
Figure 8: Type 2 VN Illustration: Case 2
図8：タイプ2 VN図：ケース2
Note that the underlay topology (which is referred to by the single abstract node topology) could be a Native/White topology or a Grey topology ([RFC8453]) that is further customized based on the requirements of the customer and configured at the MDSC.
アンダーレイトポロジ（単一の抽象ノードトポロジーによって言及されている）は、顧客の要件に基づいてさらにカスタマイズされ、MDSCで構成されているネイティブ/ホワイトトポロジまたはグレートポロジ（[RFC8453]）である可能性があることに注意してください。
Appendix B provides JSON examples for both the VN model and the TE Topology Connectivity Matrix sub-model to illustrate how a VN can be created by the CNC making use of the VN model as well as the TE Topology Connectivity Matrix module.
付録Bは、VNモデルとTEトポロジー接続マトリックスサブモデルの両方のJSONの例を提供し、VNモデルとTEトポロジー接続マトリックスモジュールを使用するCNCによってVNを作成する方法を示します。
The customer access information may be known at the time of VN creation. A shared logical AP identifier is used between the customer and the operator to identify the access link between Customer Edge (CE) and Provider Edge (PE). This is described in Section 6 of [RFC8453].
顧客アクセス情報は、VNの作成時に知られている場合があります。顧客とオペレーターの間で共有論理AP識別子が使用され、顧客エッジ（CE）とプロバイダーエッジ（PE）の間のアクセスリンクを識別します。これは、[RFC8453]のセクション6で説明されています。
In some VN operations, the customer access may not be known at the initial VN creation. The VN operation allows the creation of a VN with only a PE identifier. The customer access information could be added later.
一部のVN操作では、最初のVN作成時に顧客アクセスがわからない場合があります。VN操作により、PE識別子のみを備えたVNの作成が可能になります。顧客アクセス情報は後で追加できます。
To achieve this, the 'ap' container has a leaf for the 'pe' node that allows the AP to be created with PE information. The VN member (and VN) could use APs that initially only have PE information.
これを達成するために、「AP」コンテナには、APをPE情報で作成できる「PE」ノードの葉があります。VNメンバー（およびVN）は、最初はPE情報のみを持っているAPを使用できます。
The VN YANG data model allows the definition of a customer view and allows the customer to communicate using the VN constructs as described in [RFC8454]. It allows the grouping of edge-to-edge links (i.e., VN members) under a common umbrella of VN. This allows the customer to instantiate and view the VN as one entity, making it easier for some customers to work on VN without worrying about the details of the provider-based YANG data models.
VN Yangデータモデルは、顧客ビューの定義を可能にし、[RFC8454]に記載されているように、顧客がVNコンストラクトを使用して通信できるようにします。これにより、VNの一般的な傘下でのエッジ間リンク（つまり、VNメンバー）のグループ化が可能になります。これにより、顧客はVNを1つのエンティティとしてインスタンス化して表示することができ、一部の顧客はプロバイダーベースのYangデータモデルの詳細を心配することなくVNで作業しやすくなります。
This is similar to the benefits offered by a separate YANG data model for customer services described in [RFC8309], which states that service models do not make any assumptions about how a service is actually engineered and delivered for a customer.
これは、[RFC8309]に記載されているカスタマーサービスに別のYangデータモデルによって提供される利点に似ています。これは、サービスモデルがサービスが実際にどのように設計および配信されているかについて仮定を立てていないと述べています。
The VN could be configured at the MDSC explicitly by the CNC using the VN YANG data model. In some other cases, the VN is not explicitly configured but is instead created automatically by the MDSC based on the customer service model and local policy; even in these cases, the VN YANG data model can be used by the CNC to learn details of the underlying VN, created to meet the requirements of the customer service model.
VNは、VN Yangデータモデルを使用して、CNCによってMDSCで明示的に構成できます。他の場合には、VNは明示的に構成されていませんが、代わりにカスタマーサービスモデルとローカルポリシーに基づいてMDSCによって自動的に作成されます。これらの場合でも、VN YangデータモデルをCNCで使用して、顧客サービスモデルの要件を満たすために作成された基礎となるVNの詳細を学習できます。
The VN model supports VN compute (pre-instantiation mode) to view the full VN as a single entity before instantiation; achieving this via path computation or "compute-only" tunnel setup ([YANG-TE]) does not provide the same functionality.
VNモデルは、VN Compute（事前介入モード）をサポートして、完全なVNをインスタンス化前に単一のエンティティとして表示します。パス計算または「コンピューティングのみ」トンネルセットアップ（[Yang-Te]）を介してこれを達成しても、同じ機能は提供されません。
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE Topo | POST /nw:networks/nw:network/ |
model (w/ Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix |
abstract node and|---------------------------------------->|
constraints in | |
the conn. matrix)| HTTP 200 |
|<----------------------------------------|
| |
| |
CNC calls RPC to | RPC /vn compute |
compute the VN |---------------------------------------->|
as per the | |
referred TE-Topo | |
| |
| HTTP 200 (Computed VN) |
|<----------------------------------------|
| |
Figure 9: VN Compute with Reference to TE Topology YANG Data Model
図9：TEトポロジーヤンデータモデルを参照してVNコンピューティング
The VN compute RPC allows the optional inclusion of the constraints and the optimization criteria at the VN as well as at the individual VN-member level. Thus, the RPC can be used independently to get the computed VN result without creating an abstract topology first.
VN Compute RPCは、VNおよび個々のVNメンバーレベルでの制約と最適化基準をオプションの含めることを可能にします。したがって、RPCは、最初に抽象トポロジを作成することなく、計算されたVN結果を取得するために独立して使用できます。
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC calls RPC to | RPC /vn compute |
compute the VN |---------------------------------------->|
as per the | |
constraints and | |
VN members | |
| HTTP 200 (Computed VN) |
|<----------------------------------------|
| |
Figure 10: VN Compute
図10：VN計算
Regardless of whether the TE Topology model is referenced, the RPC output includes a reference to the single node abstract topology with each VN member including a reference to the connectivity-matrix-id where the path properties could be found.
TEトポロジモデルが参照されるかどうかにかかわらず、RPC出力には、パスプロパティが見つかるConnectivity-Matrix-IDへの参照を含む、各VNメンバーの単一ノード抽象トポロジへの参照が含まれています。
To achieve this, the VN compute RPC reuses the following common groupings:
これを達成するために、VN Compute RPCは次の共通グループを再利用します。
* te-types:generic-path-constraints: is used optionally in the RPC input at the VN-level and/or VN-member level. The VN-member level overrides the VN-level data including any constraints in the referenced abstract node in the TE topology.
* TEタイプ：Generic-Path-Constraints：VNレベルおよび/またはVNメンバーレベルのRPC入力でオプションで使用されます。VNメンバーレベルは、TEトポロジの参照される抽象ノードの制約を含むVNレベルのデータを無効にします。
* te-types:generic-path-optimization: is used optionally in the RPC input at the VN-level and/or VN-member level. The VN-member level overrides the VN-level data including any optimization in the referenced abstract node in the TE topology.
* TEタイプ：Generic-Path-Optimization：VNレベルおよび/またはVNメンバーレベルのRPC入力でオプションで使用されます。VNメンバーレベルは、TEトポロジの参照される抽象ノードの最適化を含むVNレベルのデータを無効にします。
* vn member: identifies the VN member in both RPC input and output.
* VNメンバー：RPC入力と出力の両方でVNメンバーを識別します。
* vn-policy: is used optionally in the RPC input to apply any VN-level policies.
* vn-policy：native vn-policy：VNレベルのポリシーを適用するためにRPC入力で使用されます。
When MDSC receives this RPC, it computes the VN based on the input provided in the RPC. This computation does not create a VN or reserve any resources in the system, it simply computes the resulting VN based on information at the MDSC or in coordination with the CNC. A single node abstract topology is used to convey the result of each VN member as a reference to the connectivity-matrix-id. In case of an error, the error information is included.
MDSCがこのRPCを受信すると、RPCで提供される入力に基づいてVNを計算します。この計算は、VNを作成したり、システム内のリソースを予約したりすることはなく、MDSCまたはCNCとの調整に基づいて、結果のVNを計算するだけです。単一のノード抽象トポロジを使用して、各VNメンバーの結果を接続マトリックスIDへの参照として伝達します。エラーの場合、エラー情報が含まれています。
rpcs:
+---x vn-compute
+---w input
| +---w te-topology-identifier
| | +---w provider-id? te-global-id
| | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id
| +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +---w path-constraints
| | +---w te-bandwidth
| | | +---w (technology)?
| | | ...
| | +---w link-protection? identityref
| | +---w setup-priority? uint8
| | +---w hold-priority? uint8
| | +---w signaling-type? identityref
| | +---w path-metric-bounds
| | | +---w path-metric-bound* [metric-type]
| | | ...
| | +---w path-affinities-values
| | | +---w path-affinities-value* [usage]
| | | ...
| | +---w path-affinity-names
| | | +---w path-affinity-name* [usage]
| | | ...
| | +---w path-srlgs-lists
| | | +---w path-srlgs-list* [usage]
| | | ...
| | +---w path-srlgs-names
| | | +---w path-srlgs-name* [usage]
| | | ...
| | +---w disjointness? te-path-disjointness
| +---w cos? te-types:te-ds-class
| +---w optimizations
| | +---w (algorithm)?
| | +--:(metric) {path-optimization-metric}?
| | | ...
| | +--:(objective-function)
| | {path-optimization-objective-function}?
| | ...
| +---w vn-member-list* [id]
| | +---w id vnm-id
| | +---w src
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref
| | +---w underlay
| | +---w path-constraints
| | | +---w te-bandwidth
| | | | ...
| | | +---w link-protection? identityref
| | | +---w setup-priority? uint8
| | | +---w hold-priority? uint8
| | | +---w signaling-type? identityref
| | | +---w path-metric-bounds
| | | | ...
| | | +---w path-affinities-values
| | | | ...
| | | +---w path-affinity-names
| | | | ...
| | | +---w path-srlgs-lists
| | | | ...
| | | +---w path-srlgs-names
| | | | ...
| | | +---w disjointness? te-path-disjointness
| | +---w cos? te-types:te-ds-class
| | +---w optimizations
| | +---w (algorithm)?
| | ...
| +---w vn-level-diversity? te-types:te-path-\
disjointness
+--ro output
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--ro vn-member-list* [id]
+--ro id vnm-id
+--ro src
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| +--ro multi-src? boolean {multi-src-dest}?
+--ro dest
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref
+--ro underlay
+--ro if-selected? boolean {multi-src-dest}?
+--ro compute-status? vn-compute-status
+--ro error-info
+--ro error-description? string
+--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityref
In creating a VN, the list of sources or destinations or both may not be predetermined by the customer. For instance, for a given source, there may be a list of multiple destinations to which the optimal destination may be chosen depending on the network resource situations. Likewise, for a given destination, there may also be multiple sources from which the optimal source may be chosen. In some cases, there may be a pool of multiple sources and destinations from which the optimal source-destination may be chosen. The following YANG tree shows how to model multiple sources and multiple destinations.
VNを作成する際、ソースまたは目的地のリストまたはその両方が顧客によって事前に決定されない場合があります。たとえば、特定のソースについては、ネットワークリソースの状況に応じて最適な宛先を選択できる複数の宛先のリストがある場合があります。同様に、特定の目的地については、最適なソースが選択される可能性のある複数のソースもある場合があります。場合によっては、複数のソースと目的地のプールがある場合があり、そこから最適な源泉登録が選択される可能性があります。次のヤン・ツリーは、複数のソースと複数の宛先をモデル化する方法を示しています。
module: ietf-vn
+--rw virtual-network
+--rw vn* [id]
+--rw id vn-id
+--rw te-topology-identifier
| +--rw provider-id? te-global-id
| +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member* [id]
| +--rw id vnm-id
| +--rw src
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--rw underlay
| +--ro oper-status? te-types:te-oper-status
| +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? te-types:te-admin-status
+--ro oper-status? te-types:te-oper-status
+--rw vn-level-diversity? te-types:te-path-disjointness
The VN YANG data model can easily be augmented to support the mapping of VN to the services such as L3SM and L2SM as described in [TE-SERVICE-MAPPING].
VN Yangデータモデルは、[TE-Service-Mapps]で説明されているように、L3SMやL2SMなどのサービスへのVNのマッピングをサポートするために簡単に拡張できます。
The VN YANG data model can be extended to support telemetry, performance monitoring, and network autonomics as described in [TEAS-ACTN-PM].
VN Yangデータモデルは、[TEA-ACTN-PM]に記載されているように、テレメトリ、パフォーマンス監視、ネットワーク自律論をサポートするために拡張できます。
Note that the VN YANG data model is tightly coupled with the TE Topology model [RFC8795]. Any underlay technology not supported by the TE Topology model in [RFC8795] is also not supported by the VN model. However, the VN model does include an empty container called "underlay" that can be augmented. For example, the Segment Routing (SR) Policy [RFC9256] information can be augmented for the SR underlay by a future model.
VN Yangデータモデルは、TEトポロジモデル[RFC8795]と密接に結びついていることに注意してください。[RFC8795]のTEトポロジモデルでサポートされていないアンダーレイテクノロジーも、VNモデルではサポートされていません。ただし、VNモデルには、増強できる「アンダーレイ」と呼ばれる空の容器が含まれています。たとえば、セグメントルーティング（SR）ポリシー[RFC9256]情報は、将来のモデルによってSRアンダーレイに対して拡張できます。
Apart from the te-types:generic-path-constraints and te-types:generic-path-optimization, an additional leaf called "cos" for the class of service is added to represent the Class-Type of traffic [RFC4124] to be used as one of the path constraints.
TEタイプとは別に：ジェネリックパスの制約とTEタイプ：ジェネリックパス最適化は、パス制約の1つとして使用するトラフィックのクラスタイプ[RFC4124]を表すために、サービスのクラスの「COS」と呼ばれる追加の葉が追加されます。
This section summarizes the features of the VN YANG data model.
このセクションでは、VN Yangデータモデルの機能を要約します。
* Maintenance of APs and VNAPs along with the VN
* VNとともにAPSおよびVNAPのメンテナンス
* VN construct to group of edge-to-edge links
* vnエッジとエッジへのリンクのグループへの構成
* Ability to support various VN and VNS types
* さまざまなVNおよびVNSタイプをサポートする機能
- VN Type 1: Customer configures the VN as a set of VN members. No other details need to be set by the customer, making for a simplified operation for the customer.
- VNタイプ1：顧客はVNをVNメンバーのセットとして構成します。顧客がその他の詳細を設定する必要はなく、顧客のために簡素化された操作を実現する必要はありません。
- VN Type 2: Along with VN members, the customer could also provide an abstract topology, this topology is provided by the Abstract TE Topology YANG data model.
- VNタイプ2：VNメンバーとともに、顧客は抽象的なトポロジーを提供することもできます。このトポロジーは、抽象的なTEトポロジーヤンデータモデルによって提供されます。
o Note that the VN type is not explicitly identified in the VN YANG data model, as the VN YANG data model is exactly the same for both VN Type 1 and VN Type 2. The VN type can be implicitly known based on the referenced TE topology and whether the connectivity matrix includes the underlay path (Type 2) or not (Type 1).
o VN YangデータモデルはVN Type 1とVN Type 2の両方でまったく同じであるため、VN YangデータモデルでVNタイプは明示的に識別されないことに注意してください。VNタイプは、参照されるTEトポロジーに基づいて暗黙的に知られている可能性があり、接続マトリックスには底部パス（タイプ2）が含まれるか（タイプ1）。
* VN Compute (pre-instantiate)
* VNコンピューティート（前抗抗体）
* Multi-Source / Multi-Destination
* マルチソース /マルチ表示
module: ietf-vn
+--rw access-point
| +--rw ap* [id]
| +--rw id ap-id
| +--rw pe?
| | -> /nw:networks/network/node/tet:te-node-id
| +--rw max-bandwidth? te-types:te-bandwidth
| +--rw avl-bandwidth? te-types:te-bandwidth
| +--rw vn-ap* [id]
| +--rw id ap-id
| +--rw vn? -> /virtual-network/vn/id
| +--rw abstract-node? -> /nw:networks/network/node/\
node-id
| +--rw ltp? leafref
| +--ro max-bandwidth? te-types:te-bandwidth
+--rw virtual-network
+--rw vn* [id]
+--rw id vn-id
+--rw te-topology-identifier
| +--rw provider-id? te-global-id
| +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member* [id]
| +--rw id vnm-id
| +--rw src
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--rw underlay
| +--ro oper-status? te-types:te-oper-status
| +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? te-types:te-admin-status
+--ro oper-status? te-types:te-oper-status
+--rw vn-level-diversity? te-types:te-path-disjointness
rpcs:
+---x vn-compute
+---w input
| +---w te-topology-identifier
| | +---w provider-id? te-global-id
| | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id
| +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +---w path-constraints
| | +---w te-bandwidth
| | | +---w (technology)?
| | | ...
| | +---w link-protection? identityref
| | +---w setup-priority? uint8
| | +---w hold-priority? uint8
| | +---w signaling-type? identityref
| | +---w path-metric-bounds
| | | +---w path-metric-bound* [metric-type]
| | | ...
| | +---w path-affinities-values
| | | +---w path-affinities-value* [usage]
| | | ...
| | +---w path-affinity-names
| | | +---w path-affinity-name* [usage]
| | | ...
| | +---w path-srlgs-lists
| | | +---w path-srlgs-list* [usage]
| | | ...
| | +---w path-srlgs-names
| | | +---w path-srlgs-name* [usage]
| | | ...
| | +---w disjointness? te-path-disjointness
| +---w cos? te-types:te-ds-class
| +---w optimizations
| | +---w (algorithm)?
| | +--:(metric) {path-optimization-metric}?
| | | ...
| | +--:(objective-function)
| | {path-optimization-objective-function}?
| | ...
| +---w vn-member-list* [id]
| | +---w id vnm-id
| | +---w src
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref
| | +---w underlay
| | +---w path-constraints
| | | +---w te-bandwidth
| | | | ...
| | | +---w link-protection? identityref
| | | +---w setup-priority? uint8
| | | +---w hold-priority? uint8
| | | +---w signaling-type? identityref
| | | +---w path-metric-bounds
| | | | ...
| | | +---w path-affinities-values
| | | | ...
| | | +---w path-affinity-names
| | | | ...
| | | +---w path-srlgs-lists
| | | | ...
| | | +---w path-srlgs-names
| | | | ...
| | | +---w disjointness? te-path-disjointness
| | +---w cos? te-types:te-ds-class
| | +---w optimizations
| | +---w (algorithm)?
| | ...
| +---w vn-level-diversity? te-types:te-path-\
disjointness
+--ro output
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--ro vn-member-list* [id]
+--ro id vnm-id
+--ro src
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| +--ro multi-src? boolean {multi-src-dest}?
+--ro dest
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref
+--ro underlay
+--ro if-selected? boolean {multi-src-\
dest}?
+--ro compute-status? vn-compute-status
+--ro error-info
+--ro error-description? string
+--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityref
The VN YANG data model is as follows:
VN Yangデータモデルは次のとおりです。
module ietf-vn {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix vn;
/* Import common YANG types */
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
/* Import network */
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
/* Import network topology */
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
/* Import TE Common types */
import ietf-te-types {
prefix te-types;
reference
"RFC 8776: Common YANG Data Types for Traffic Engineering";
}
/* Import TE Topology */
import ietf-te-topology {
prefix tet;
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Young Lee <younglee.tx@gmail.com>
Editor: Dhruv Dhody <dhruv.ietf@gmail.com>";
description
"This YANG module for the Virtual Network (VN).
It describes a VN operation module that can take place
in the context of the Customer Network Controller (CNC) -
Multi-Domain Service Coordinator (MDSC) interface (CMI) of
the Abstraction and Control of TE Networks (ACTN)
architecture where the CNC is the actor of a VN
instantiation/modification/deletion as per RFC 8453.
Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9731; see the
RFC itself for full legal notices.";
revision 2025-03-27 {
description
"The initial version.";
reference
"RFC 9731: A YANG Data Model for Virtual Network (VN)
Operations";
}
/* Features */
feature multi-src-dest {
description
"Support for selection of one source or destination
among multiple.";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
/* Typedef */
typedef vn-id {
type string {
length "1..max";
}
description
"A type definition for a VN identifier.";
}
typedef ap-id {
type string {
length "1..max";
}
description
"A type definition for an Access Point (AP) identifier.";
}
typedef vnm-id {
type string {
length "1..max";
}
description
"A type definition for a VN-member identifier.";
}
typedef vn-compute-status {
type te-types:te-common-status;
description
"A type definition for representing the VN compute status.
Note that all statuses apart from up and down are considered
to be unknown.";
}
/* identities */
identity vn-computation-error-reason {
description
"Base identity for VN computation error reasons.";
}
identity vn-computation-error-not-ready {
base vn-computation-error-reason;
description
"VN computation has failed because the MDSC is not
ready.";
}
identity vn-computation-error-no-cnc {
base vn-computation-error-reason;
description
"VN computation has failed because one or more dependent
CNCs are unavailable.";
}
identity vn-computation-error-no-resource {
base vn-computation-error-reason;
description
"VN computation has failed because there is no
available resource in one or more domains.";
}
identity vn-computation-error-path-not-found {
base vn-computation-error-reason;
description
"VN computation failed as no path found.";
}
identity vn-computation-ap-unknown {
base vn-computation-error-reason;
description
"VN computation failed as the source or destination Access
Point (AP) not known.";
}
/* Groupings */
grouping vn-member {
description
"The vn-member is described by this grouping.";
leaf id {
type vnm-id;
description
"A vn-member identifier.";
}
container src {
description
"The source of VN member.";
leaf ap {
type leafref {
path "/access-point/ap/id";
}
description
"A reference to the source AP.";
}
leaf vn-ap-id {
type leafref {
path "/access-point/ap[id=current()/../ap]/vn-ap"
+ "/id";
}
description
"A reference to the source VNAP.";
}
leaf multi-src {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the source part of a multi-source, where
only one of the sources is enabled?";
}
}
container dest {
description
"The destination of the VN member.";
leaf ap {
type leafref {
path "/access-point/ap/id";
}
description
"A reference to the destination AP.";
}
leaf vn-ap-id {
type leafref {
path "/access-point/ap[id=current()/../ap]/"
+ "vn-ap/id";
}
description
"A reference to the destination VNAP.";
}
leaf multi-dest {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the destination part of a multi-destination,
where only one of the destinations is enabled.";
}
}
leaf connectivity-matrix-id {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/"
+ "tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:id";
}
description
"A reference to the connectivity-matrix.";
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
container underlay {
description
"An empty container that can be augmented with underlay
technology information not supported by RFC 8795 (for
example, Segment Routing (SR).";
}
reference
"RFC 8454: Information Model for Abstraction and Control of TE
Networks (ACTN)
RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
grouping vn-policy {
description
"policy for VN-level diversity";
leaf vn-level-diversity {
type te-types:te-path-disjointness;
description
"The type of disjointness on the VN level (i.e., across all
VN members).";
}
}
/* Configuration data nodes */
container access-point {
description
"AP configurations.";
list ap {
key "id";
description
"The access-point identifier.";
leaf id {
type ap-id;
description
"An AP identifier unique within the scope of the entity
that controls the VN.";
}
leaf pe {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the PE node in the native TE Topology.";
}
leaf max-bandwidth {
type te-types:te-bandwidth;
description
"The max bandwidth of the AP.";
}
leaf avl-bandwidth {
type te-types:te-bandwidth;
description
"The available bandwidth of the AP.";
}
list vn-ap {
key "id";
leaf id {
type ap-id;
description
"A unique identifier for the VNAP.";
}
leaf vn {
type leafref {
path "/virtual-network/vn/id";
}
description
"A reference to the VN.";
}
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id";
}
must '/nw:networks/nw:network/nw:node[nw:node-id='
+ 'current()/../abstract-node]/tet:te-node-id' {
description
"The associated network for the abstract-node
must be TE enabled.";
}
description
"A reference to the abstract node that represents
the VN.";
}
leaf ltp {
type leafref {
path "/nw:networks/nw:network/nw:node[nw:node-id="
+ "current()/../abstract-node]/nt:termination-point/"
+ "tet:te-tp-id";
}
description
"A reference to the Link Termination Point (LTP)
in the abstract-node, i.e., the LTP should be in
the abstract layer and not the underlying layer.";
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
leaf max-bandwidth {
type te-types:te-bandwidth;
config false;
description
"The max bandwidth of the VNAP.";
}
description
"List of VNAPs in this AP.";
}
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 6";
}
container virtual-network {
description
"VN configurations.";
list vn {
key "id";
description
"A VN is identified by a vn-id.";
leaf id {
type vn-id;
description
"An identifier unique within the scope of the entity
that controls the VN.";
}
uses te-types:te-topology-identifier;
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the abstract node in TE Topology.";
}
list vn-member {
key "id";
description
"List of vn-members in a VN.";
uses vn-member;
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"The vn-member operational state.";
}
leaf if-selected {
if-feature "multi-src-dest";
type boolean;
default "false";
config false;
description
"Is the vn-member selected among the multi-source
or multi-destination options?";
}
}
leaf admin-status {
type te-types:te-admin-status;
default "up";
description
"VN administrative state.";
}
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"VN operational state.";
}
uses vn-policy;
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
/* RPC */
rpc vn-compute {
description
"The VN computation without actual instantiation. This is
used by the CNC to get the VN results without actually
creating it in the network.
The input could include a reference to the single node
abstract topology. It could optionally also include
constraints and optimization criteria. The computation
is done based on the list of VN members.
The output includes a reference to the single node
abstract topology with each VN member including a
reference to the connectivity-matrix-id where the
path properties could be found. Error information is
also included.";
input {
uses te-types:te-topology-identifier;
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the abstract node in TE Topology.";
}
uses te-types:generic-path-constraints;
leaf cos {
type te-types:te-ds-class;
description
"The class of service (COS).";
}
uses te-types:generic-path-optimization;
list vn-member-list {
key "id";
description
"List of VN members in a VN.";
uses vn-member;
uses te-types:generic-path-constraints;
leaf cos {
type te-types:te-ds-class;
description
"The class of service.";
reference
"RFC 4124: Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering,
Section 4.3.1";
}
uses te-types:generic-path-optimization;
}
uses vn-policy;
}
output {
uses te-types:te-topology-identifier;
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the abstract node in TE Topology.";
}
list vn-member-list {
key "id";
description
"List of VN members in a VN.";
uses vn-member;
leaf if-selected {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the vn-member selected among the multi-source or
multi-destination options?";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 7";
}
leaf compute-status {
type vn-compute-status;
description
"The VN-member compute state.";
}
container error-info {
description
"Error information related to the VN member.";
leaf error-description {
type string {
length "1..max";
}
description
"Textual representation of the error that occurred
during VN compute.";
}
leaf error-timestamp {
type yang:date-and-time;
description
"Timestamp of the attempt.";
}
leaf error-reason {
type identityref {
base vn-computation-error-reason;
}
description
"Reason for the VN computation error.";
}
}
}
}
}
}
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
このドキュメントで指定されたYangモジュールは、NetConf [RFC6241]やRestConf [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義しています。最低のネットコン層は安全な輸送層であり、実装から実装の安全な輸送は安全なシェル（SSH）[RFC6242]です。最も低いRESTCONF層はHTTPSであり、実装対象の安全な輸送はTLS [RFC8446]です。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、利用可能なすべてのNetConfまたはRestConfプロトコル操作とコンテンツの事前に設定されたサブセットに特定のNetConfまたはRestConfユーザーのアクセスを制限する手段を提供します。
The model presented in this document is used in the interface between the CNC and MDSC, which is referred to as CNC-MDSC Interface (CMI). Security risks, such as malicious attack and rogue elements attempting to connect to the various ACTN components, are possible. Furthermore, some ACTN components (e.g., MDSC) represent a single point of failure and threat vector. Also, there is a need to manage policy conflicts and eavesdropping on communication between different ACTN components.
このドキュメントに示されているモデルは、CNCとMDSCの間のインターフェースで使用されており、CNC-MDSCインターフェイス（CMI）と呼ばれます。さまざまなACTNコンポーネントに接続しようとする悪意のある攻撃や不正な要素などのセキュリティリスクが可能です。さらに、一部のACTNコンポーネント（MDSCなど）は、障害と脅威ベクトルの単一のポイントを表しています。また、さまざまなACTNコンポーネント間の通信を政策の競合と盗聴を管理する必要があります。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYangモジュールには、作成可能/クリエーション/削除可能な（つまり、デフォルトである「config true」）というデータノードが多数あります。これらのデータノードは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしにこれらのデータノードに操作を書き込む（例：編集config）は、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノードとその感度/脆弱性です。
* ap: This list includes a set of sensitive data that influences how the APs in the VN service are attached. By accessing the following data nodes, an attacker may be able to manipulate the VN.
* AP：このリストには、VNサービスのAPがどのように添付されるかに影響を与える機密データのセットが含まれています。次のデータノードにアクセスすることにより、攻撃者がVNを操作できる場合があります。
- id
- id
- pe
- PE
- max-bandwidth
- 最大帯域幅
- avl-bandwidth
- avl-bandwidth
* vn-ap: This list includes a set of sensitive data that influences how the VN service is delivered. By accessing the following data nodes, an attacker may be able to manipulate the VN.
* VN-AP：このリストには、VNサービスの配信方法に影響を与える機密データのセットが含まれています。次のデータノードにアクセスすることにより、攻撃者がVNを操作できる場合があります。
- id
- id
- vn
- vn
- abstract-node
- 要約ノード
- ltp
- LTP
- max-bandwidth
- 最大帯域幅
* vn: This list includes a set of sensitive data that influences how the VN service is delivered. By accessing the following data nodes, an attacker may be able to manipulate the VN.
* VN：このリストには、VNサービスの配信方法に影響を与える機密データのセットが含まれています。次のデータノードにアクセスすることにより、攻撃者がVNを操作できる場合があります。
- id
- id
- te-topology-identifier
- Te-Topology-Identifier
- abstract-node
- 要約ノード
* vn-member: This list includes a set of sensitive data that influences how the VN member in the VN service is delivered. By accessing the following data nodes, an attacker may be able to manipulate the VN member.
* VNメンバー：このリストには、VNサービスのVNメンバーがどのように配信されるかに影響を与える機密データのセットが含まれています。次のデータノードにアクセスすることにより、攻撃者がVNメンバーを操作できる場合があります。
- id
- id
- src/ap
- SRC/AP
- src/vn-ap-id
- SRC/VN-AP-ID
- dest/ap
- DEST/AP
- dest/vn-ap-id
- DEST/VN-AP-ID
- connectivity-matrix-id
- Connectivity-Matrix-ID
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYangモジュールの読み取り可能なデータノードの一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのデータノードへの読み取りアクセス（GET、GetConfig、または通知を介して）を制御することが重要です。これらは、サブツリーとデータノードとその感度/脆弱性です。
* oper-status: This leaf can reveal the current operational state of the VN.
* オペレーション：この葉は、VNの現在の動作状態を明らかにすることができます。
* if-selected: This leaf can reveal which vn-member is selected among the various multi-source / multi-destination options.
* 選択された場合：この葉は、さまざまなマルチソース /マルチデスティングオプションの中から選択されているVNメンバーを明らかにすることができます。
Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability:
このヤンモジュールのRPC操作の一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらの操作へのアクセスを制御することが重要です。これらは、操作とその感度/脆弱性です。
* vn-compute: This RPC triggers the VN computation at the MDSC, which can reveal the VN information.
* VN-Compute：このRPCは、MDSCでVN計算をトリガーし、VN情報を明らかにすることができます。
IANA has made the following allocation for a URI in the "ns" registry within the "IETF XML Registry" registry group [RFC3688]:
IANAは、「IETF XMLレジストリ」レジストリグループ[RFC3688]内の「NS」レジストリでURIに次の割り当てを行いました。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-vn
urn：ietf：params：xml：ns：yang：ietf-vn
Registrant Contact:
登録者の連絡先：
The IESG.
IESG。
XML:
XML:
N/A, the requested URI is an XML namespace.
N/A、要求されたURIはXMLネームスペースです。
IANA has made the following allocation for the VN YANG data model (see Section 5 in the "YANG Module Names" registry [RFC6020]:
IANAは、VN Yangデータモデルに次の割り当てを行いました（「Yangモジュール名」レジストリ[RFC6020]のセクション5を参照してください。
name:
名前：
ietf-vn
IETF-VN
namespace:
名前空間：
urn:ietf:params:xml:ns:yang:ietf-vn
urn：ietf：params：xml：ns：yang：ietf-vn
prefix:
プレフィックス：
vn
vn
reference:
参照：
RFC 9731
RFC 9731
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
DOI 10.17487/RFC4124, June 2005,
<https://www.rfc-editor.org/info/rfc4124>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/info/rfc8776>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
[L1CSM-YANG]
Lee, Y., Lee, K., Zheng, H., Gonzalez de Dios, O., and D.
Ceccarelli, "A YANG Data Model for L1 Connectivity Service
Model (L1CSM)", Work in Progress, Internet-Draft, draft-
ietf-ccamp-l1csm-yang-26, 11 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
l1csm-yang-26>.
[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>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[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>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[TE-SERVICE-MAPPING]
Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D.,
and J. Tantsura, "Traffic Engineering (TE) and Service
Mapping YANG Data Model", Work in Progress, Internet-
Draft, draft-ietf-teas-te-service-mapping-yang-17, 29
January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-te-service-mapping-yang-17>.
[TEAS-ACTN-PM]
Lee, Y., Dhody, D., Vilalta, R., King, D., and D.
Ceccarelli, "YANG models for Virtual Network (VN)/TE
Performance Monitoring Telemetry and Scaling Intent
Autonomics", Work in Progress, Internet-Draft, draft-ietf-
teas-actn-pm-telemetry-autonomics-14, 19 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
actn-pm-telemetry-autonomics-14>.
[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-37>.
At the creation of a VN, it is natural to provide VN-level constraints and optimization criteria. It should be noted that the VN YANG data model described in this document relies on the TE Topology model in [RFC8795] by using a reference to an abstract node to provide VN-level constraints and optimization criteria. Further, the connectivity-matrix structure is used to assign the constraints and optimization criteria including delay, jitter, etc. [RFC8776] defines some of the metric-types; future documents are meant to augment it.
VNの作成では、VNレベルの制約と最適化基準を提供することは自然です。このドキュメントに記載されているVN Yangデータモデルは、抽象ノードへの参照を使用してVNレベルの制約と最適化基準を提供することにより、[RFC8795]のTEトポロジモデルに依存していることに注意する必要があります。さらに、接続マトリックス構造は、遅延、ジッターなどを含む制約と最適化基準を割り当てるために使用されます。[RFC8776]は、メトリックタイプの一部を定義します。将来の文書はそれを補強することを目的としています。
Note that the VN compute allows the inclusion of the constraints and the optimization criteria directly in the RPC to allow it to be used independently.
VN計算により、RPCに制約と最適化基準を直接含めると、独立して使用できるようにすることに注意してください。
This section provides JSON examples of how the VN YANG data model and TE Topology YANG data model are used together to instantiate a VN.
このセクションでは、VN YangデータモデルとTEトポロジーYangデータモデルがVNをインスタンス化するためにどのように使用されるかのJSONの例を示します。
The example in this section includes the following VNs:
このセクションの例には、次のVNが含まれています。
* VN1 (Type 1): This VN maps to the single node topology abstract1 and consists of VN members 104 (L1 to L4), 107 (L1 to L7), 204 (L2 to L4), 308 (L3 to L8), and 108 (L1 to L8).
* VN1（タイプ1）：このVNは、単一ノードトポロジーAbstract1にマップし、VNメンバー104（L1〜L4）、107（L1〜L7）、204（L2からL4）、308（L3からL8）、および108（L1からL8）で構成されています。
* VN2 (Type 2): This VN maps to the single node topology abstract2; this topology has an underlay topology (called underlay). This VN has a single VN member 105 (L1 to L5) and an underlay path (S4 and S7) has been set in the connectivity matrix of the abstract2 topology;
* VN2（タイプ2）：このVNは、単一ノードトポロジーAbstract2にマップします。このトポロジには、アンダーレイトポロジ（アンダーレイと呼ばれます）があります。このVNには単一のVNメンバー105（L1〜L5）があり、アンダーレイパス（S4およびS7）がAbstract2トポロジの接続マトリックスに設定されています。
* VN3 (Type 1): This VN has a multi-source and multi-destination feature enabled. VN member 106 (L1 to L6) and 107 (L1 to L7) showcase multi-dest and VN member 108 (L1 to L8) and 308 (L3 to L8) showcase the multi-src feature. The selected VN member is known via the field "if-selected" and the corresponding connectivity-matrix-id.
* VN3（タイプ1）：このVNには、マルチソースとマルチデスティング機能が有効になっています。VNメンバー106（L1〜L6）および107（L1からL7）は、マルチデストとVNメンバー108（L1〜L8）と308（L3からL8）を紹介します。マルチSRC機能を示します。選択されたVNメンバーは、フィールド「IF選択」と対応する接続Matrix-IDを介して知られています。
L1---104---L4 L1---105---L5 L1---106---L6(md)
L1---107---L7 Underlay Path: L1---107---L7(md)
L2---204---L4 (S4 and S7) L1---108---L8(ms)
L3---308---L8 L3---308---L8(ms)
L1---108---L8
--- --- ---
VN1 VN2 VN3
--- --- ---
Figure 11: Example
図11：例
Note that the VN YANG data model also includes the AP and VNAP, which shows various VNs using the same AP.
VN Yangデータモデルには、同じAPを使用してさまざまなVNを示すAPとVNAPも含まれていることに注意してください。
{
"ietf-vn:access-point": {
"ap": [
{
"id": "101",
"vn-ap": [
{
"id": "10101",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.11"
},
{
"id": "10102",
"vn": "2",
"abstract-node": "192.0.2.2",
"ltp": "203.0.113.12"
},
{
"id": "10103",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.13"
}
]
},
{
"id": "202",
"vn-ap": [
{
"id": "20201",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.21"
}
]
},
{
"id": "303",
"vn-ap": [
{
"id": "30301",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.31"
},
{
"id": "30303",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.33"
}
]
},
{
"id": "404",
"vn-ap": [
{
"id": "40401",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.41"
}
]
},
{
"id": "505",
"vn-ap": [
{
"id": "50502",
"vn": "2",
"abstract-node": "192.0.2.2",
"ltp": "203.0.113.52"
}
]
},
{
"id": "606",
"vn-ap": [
{
"id": "60603",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.63"
}
]
},
{
"id": "707",
"vn-ap": [
{
"id": "70701",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.71"
},
{
"id": "70703",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.73"
}
]
},
{
"id": "808",
"vn-ap": [
{
"id": "80801",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.81"
},
{
"id": "80803",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.83"
}
]
}
]
},
"ietf-vn:virtual-network": {
"vn": [
{
"id": "1",
"te-topology-identifier": {
"topology-id": "abstract1"
},
"abstract-node": "192.0.2.1",
"vn-member": [
{
"id": "104",
"src": {
"ap": "101",
"vn-ap-id": "10101"
},
"dest": {
"ap": "404",
"vn-ap-id": "40401"
},
"connectivity-matrix-id": 10104
},
{
"id": "107",
"src": {
"ap": "101",
"vn-ap-id": "10101"
},
"dest": {
"ap": "707",
"vn-ap-id": "70701"
},
"connectivity-matrix-id": 10107
},
{
"id": "204",
"src": {
"ap": "202",
"vn-ap-id": "20201"
},
"dest": {
"ap": "404",
"vn-ap-id": "40401"
},
"connectivity-matrix-id": 10204
},
{
"id": "308",
"src": {
"ap": "303",
"vn-ap-id": "30301"
},
"dest": {
"ap": "808",
"vn-ap-id": "80801"
},
"connectivity-matrix-id": 10308
},
{
"id": "108",
"src": {
"ap": "101",
"vn-ap-id": "10101"
},
"dest": {
"ap": "808",
"vn-ap-id": "80801"
},
"connectivity-matrix-id": 10108
}
]
},
{
"id": "2",
"te-topology-identifier": {
"topology-id": "abstract2"
},
"abstract-node": "192.0.2.2",
"vn-member": [
{
"id": "105",
"src": {
"ap": "101",
"vn-ap-id": "10102"
},
"dest": {
"ap": "505",
"vn-ap-id": "50502"
},
"connectivity-matrix-id": 20105
}
]
},
{
"id": "3",
"te-topology-identifier": {
"topology-id": "abstract3"
},
"abstract-node": "192.0.2.3",
"vn-member": [
{
"id": "106",
"src": {
"ap": "101",
"vn-ap-id": "10103"
},
"dest": {
"ap": "606",
"vn-ap-id": "60603",
"multi-dest": true
},
"connectivity-matrix-id": 30106,
"if-selected": false
},
{
"id": "107",
"src": {
"ap": "101",
"vn-ap-id": "10103"
},
"dest": {
"ap": "707",
"vn-ap-id": "70703",
"multi-dest": true
},
"connectivity-matrix-id": 30107,
"if-selected": true
},
{
"id": "108",
"src": {
"ap": "101",
"vn-ap-id": "10103",
"multi-src": true
},
"dest": {
"ap": "808",
"vn-ap-id": "80803",
},
"connectivity-matrix-id": 30108,
"if-selected": false
},
{
"id": "308",
"src": {
"ap": "303",
"vn-ap-id": "30303",
"multi-src": true
},
"dest": {
"ap": "808",
"vn-ap-id": "80803"
},
"connectivity-matrix-id": 30308,
"if-selected": true
}
]
}
]
}
}
This section provides JSON examples of the various TE topology instances.
このセクションでは、JSONのさまざまなTEトポロジインスタンスの例を示します。
The example in this section includes the following TE Topologies:
このセクションの例には、次のTEトポロジが含まれています。
* abstract1: a single node TE topology referenced by VN1. We also show how disjointness (node, link, Shared Risk Link Group (SRLG)) is supported in the example on the connectivity matrices.
* Abstract1：VN1が参照する単一のノードTEトポロジ。また、接続マトリックスの例で、どのように分離（ノード、リンク、共有リスクリンクグループ（SRLG））がサポートされているかを示します。
* abstract2: a single node TE topology referenced by VN2 with an underlay path.
* Abstract2：アンダーレイパスを持つVN2が参照する単一のノードTEトポロジ。
* underlay: the topology with multiple nodes (in the underlay path of abstract2). For brevity, the example includes only the node: other parameters are not included.
* アンダーレイ：複数のノードを備えたトポロジー（Abstract2のアンダーレイパス）。簡潔にするために、この例にはノードのみが含まれます。他のパラメーターは含まれていません。
* abstract3: a single node TE topology referenced by VN3.
* Abstract3：VN3が参照する単一のノードTEトポロジ。
{
"ietf-network:networks": {
"network": [
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:abstract1",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:abstract1"
},
"node": [
{
"node-id": "example:192.0.2.1",
"ietf-network-topology:termination-point": [
{
"tp-id": "example:1-0-1",
"ietf-te-topology:te-tp-id": "203.0.113.11"
},
{
"tp-id": "example:1-0-2",
"ietf-te-topology:te-tp-id": "203.0.113.21"
},
{
"tp-id": "example:1-0-3",
"ietf-te-topology:te-tp-id": "203.0.113.31"
},
{
"tp-id": "example:1-0-4",
"ietf-te-topology:te-tp-id": "203.0.113.41"
},
{
"tp-id": "example:1-0-7",
"ietf-te-topology:te-tp-id": "203.0.113.71"
},
{
"tp-id": "example:1-0-8",
"ietf-te-topology:te-tp-id": "203.0.113.81"
}
],
"ietf-te-topology:te-node-id": "192.0.2.1",
"ietf-te-topology:te": {
"te-node-attributes": {
"domain-id": 1,
"is-abstract": [
null
],
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"te-bandwidth": {
"generic": "0x1p10"
},
"disjointness": "node link srlg"
},
"connectivity-matrix": [
{
"id": 10104,
"from": {
"tp-ref": "example:1-0-1"
},
"to": {
"tp-ref": "example:1-0-4"
}
},
{
"id": 10107,
"from": {
"tp-ref": "example:1-0-1"
},
"to": {
"tp-ref": "example:1-0-7"
}
},
{
"id": 10204,
"from": {
"tp-ref": "example:1-0-2"
},
"to": {
"tp-ref": "example:1-0-4"
}
},
{
"id": 10308,
"from": {
"tp-ref": "example:1-0-3"
},
"to": {
"tp-ref": "example:1-0-8"
}
},
{
"id": 10108,
"from": {
"tp-ref": "example:1-0-1"
},
"to": {
"tp-ref": "example:1-0-8"
}
}
]
}
}
}
}
]
},
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:abstract2",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:abstract2"
},
"node": [
{
"node-id": "example:192.0.2.2",
"ietf-network-topology:termination-point": [
{
"tp-id": "example:2-0-1",
"ietf-te-topology:te-tp-id": "203.0.113.12"
},
{
"tp-id": "example:2-0-5",
"ietf-te-topology:te-tp-id": "203.0.113.52"
}
],
"ietf-te-topology:te-node-id": "192.0.2.2",
"ietf-te-topology:te": {
"te-node-attributes": {
"domain-id": 1,
"is-abstract": [
null
],
"connectivity-matrices": {
"is-allowed": true,
"underlay": {
"enabled": true
},
"path-constraints": {
"te-bandwidth": {
"generic": "0x1p10"
}
},
"optimizations": {
"objective-function": {
"objective-function-type":
"ietf-te-types:of-maximize-residual-bandwidth"
}
},
"ietf-te-topology:connectivity-matrix": [
{
"id": 20105,
"from": {
"tp-ref": "example:2-0-1"
},
"to": {
"tp-ref": "example:2-0-5"
},
"underlay": {
"enabled": true,
"primary-path": {
"network-ref": "example:underlay",
"path-element": [
{
"path-element-id": 1,
"numbered-node-hop": {
"node-id": "198.51.100.44",
"hop-type": "strict"
}
},
{
"path-element-id": 2,
"numbered-node-hop": {
"node-id": "198.51.100.77",
"hop-type": "strict"
}
}
]
}
}
}
]
}
}
}
}
]
},
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:underlay",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:underlay"
},
"node": [
{
"node-id": "example:198.51.100.11",
"ietf-te-topology:te-node-id": "198.51.100.11"
},
{
"node-id": "example:198.51.100.22",
"ietf-te-topology:te-node-id": "198.51.100.22"
},
{
"node-id": "example:198.51.100.33",
"ietf-te-topology:te-node-id": "198.51.100.33"
},
{
"node-id": "example:198.51.100.44",
"ietf-te-topology:te-node-id": "198.51.100.44"
},
{
"node-id": "example:198.51.100.55",
"ietf-te-topology:te-node-id": "198.51.100.55"
},
{
"node-id": "example:198.51.100.66",
"ietf-te-topology:te-node-id": "198.51.100.66"
},
{
"node-id": "example:198.51.100.77",
"ietf-te-topology:te-node-id": "198.51.100.77"
},
{
"node-id": "example:198.51.100.88",
"ietf-te-topology:te-node-id": "198.51.100.88"
},
{
"node-id": "example:198.51.100.99",
"ietf-te-topology:te-node-id": "198.51.100.99"
}
]
},
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:abstract3",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:abstract3"
},
"node": [
{
"node-id": "example:192.0.2.3",
"ietf-network-topology:termination-point": [
{
"tp-id": "example:3-0-1",
"ietf-te-topology:te-tp-id": "203.0.113.13"
},
{
"tp-id": "example:3-0-3",
"ietf-te-topology:te-tp-id": "203.0.113.33"
},
{
"tp-id": "example:3-0-6",
"ietf-te-topology:te-tp-id": "203.0.113.63"
},
{
"tp-id": "example:3-0-7",
"ietf-te-topology:te-tp-id": "203.0.113.73"
},
{
"tp-id": "example:3-0-8",
"ietf-te-topology:te-tp-id": "203.0.113.83"
}
],
"ietf-te-topology:te-node-id": "192.0.2.3",
"ietf-te-topology:te": {
"te-node-attributes": {
"domain-id": 3,
"is-abstract": [
null
],
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"te-bandwidth": {
"generic": "0x1p10"
}
},
"connectivity-matrix": [
{
"id": 30107,
"from": {
"tp-ref": "example:3-0-1"
},
"to": {
"tp-ref": "example:3-0-7"
}
},
{
"id": 30106,
"from": {
"tp-ref": "example:3-0-1"
},
"to": {
"tp-ref": "example:3-0-6"
}
},
{
"id": 30108,
"from": {
"tp-ref": "example:3-0-1"
},
"to": {
"tp-ref": "example:3-0-8"
}
},
{
"id": 30308,
"from": {
"tp-ref": "example:3-0-3"
},
"to": {
"tp-ref": "example:3-0-8"
}
}
]
}
}
}
}
]
}
]
}
}
The authors would like to thank Xufeng Liu, Adrian Farrel, Tom Petch, Mohamed Boucadair, Italo Busi, Bo Wu, and Daniel King for their helpful comments and valuable suggestions.
著者は、Xufeng Liu、Adrian Farrel、Tom Petch、Mohamed Boucadair、Italo Busi、Bo Wu、およびDaniel Kingの有益なコメントと貴重な提案に感謝したいと思います。
Thanks to:
ありがとう：
* Andy Bierman for the YANGDIR review.
* YangdirレビューのAndy Bierman。
* Darren Dukes and Susan Hares for the RTGDIR review.
* RTGDIRレビューのために、Darren DukesとSusan Hares。
* Behcet Sarikaya for the GENART review.
* Genart ReviewのためにSarikayaをBehcet。
* Bo Wu for the OPSDIR review.
* OPSDIRレビューのためのBo Wu。
* Shivan Sahib for the SECDIR review.
* SecdirレビューのShivan Sahib。
* Deb Cooley, Francesca Palombini, Gunter Van de Velde, and Mahesh Jethanandani for the IESG review.
* IESGレビューのために、Deb Cooley、Francesca Palombini、Gunter Van de Velde、Mahesh Jethanandani。
Qin Wu
Huawei Technologies
Email: bill.wu@huawei.com
Peter Park
KT
Email: peter.park@kt.com
Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Takuya Miyasaka
KDDI
Email: ta-miyasaka@kddi.com
Kenichi Ogaki
KDDI
Email: ke-oogaki@kddi.com
Young Lee (editor)
Samsung Electronics
Email: younglee.tx@gmail.com
Dhruv Dhody (editor)
Huawei
India
Email: dhruv.ietf@gmail.com
Daniele Ceccarelli
Cisco
Email: daniele.ietf@gmail.com
Igor Bryskin
Individual
Email: i_bryskin@yahoo.com
Bin Yeong Yoon
ETRI
Email: byyun@etri.re.kr