Internet Engineering Task Force (IETF) A. Clemm
Request for Comments: 8345 Huawei
Category: Standards Track J. Medved
ISSN: 2070-1721 Cisco
R. Varga
Pantheon Technologies SRO
N. Bahadur
Bracket Computing
H. Ananthakrishnan
Packet Design
X. Liu
Jabil
March 2018
Internet Engineering Task Force (IETF) A. Clemm
Request for Comments: 8345 Huawei
Category: Standards Track J. Medved
ISSN: 2070-1721 Cisco
R. Varga
Pantheon Technologies SRO
N. Bahadur
Bracket Computing
H. Ananthakrishnan
Packet Design
X. Liu
Jabil
March 2018
A YANG Data Model for Network Topologies
网络拓扑的YANG数据模型
Abstract
摘要
This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.
本文档定义了网络/服务拓扑和清单的抽象（通用或基本）数据模型。该数据模型作为基础模型，在其他更具体的拓扑和库存数据模型中添加了特定于技术的详细信息。
Status of This Memo
关于下段备忘
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/rfc8345.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8345.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Key Words .......................................................8
3. Definitions and Abbreviations ...................................9
4. Model Structure Details .........................................9
4.1. Base Network Model .........................................9
4.2. Base Network Topology Data Model ..........................12
4.3. Extending the Data Model ..................................13
4.4. Discussion and Selected Design Decisions ..................14
4.4.1. Container Structure ................................14
4.4.2. Underlay Hierarchies and Mappings ..................14
4.4.3. Dealing with Changes in Underlay Networks ..........15
4.4.4. Use of Groupings ...................................15
4.4.5. Cardinality and Directionality of Links ............16
4.4.6. Multihoming and Link Aggregation ...................16
4.4.7. Mapping Redundancy .................................16
4.4.8. Typing .............................................17
4.4.9. Representing the Same Device in Multiple Networks ..17
4.4.10. Supporting Client-Configured and
System-Controlled Network Topologies ..............18
4.4.11. Identifiers of String or URI Type .................19
5. Interactions with Other YANG Modules ...........................19
6. YANG Modules ...................................................20
6.1. Defining the Abstract Network: ietf-network ...............20
6.2. Creating Abstract Network Topology:
ietf-network-topology .....................................25
7. IANA Considerations ............................................32
8. Security Considerations ........................................33
9. References .....................................................35
9.1. Normative References ......................................35
9.2. Informative References ....................................36
Appendix A. Model Use Cases .......................................38
A.1. Fetching Topology from a Network Element ...................38
A.2. Modifying TE Topology Imported from an Optical Controller ..38
A.3. Annotating Topology for Local Computation ..................39
A.4. SDN Controller-Based Configuration of Overlays on Top of
Underlays ..................................................39
Appendix B. Companion YANG Data Models for Implementations Not
Compliant with NMDA ...................................39
B.1. YANG Module for Network State ..............................40
B.2. YANG Module for Network Topology State .....................45
Appendix C. An Example ............................................52
Acknowledgments ...................................................56
Contributors ......................................................56
Authors' Addresses ................................................57
1. Introduction ....................................................4
2. Key Words .......................................................8
3. Definitions and Abbreviations ...................................9
4. Model Structure Details .........................................9
4.1. Base Network Model .........................................9
4.2. Base Network Topology Data Model ..........................12
4.3. Extending the Data Model ..................................13
4.4. Discussion and Selected Design Decisions ..................14
4.4.1. Container Structure ................................14
4.4.2. Underlay Hierarchies and Mappings ..................14
4.4.3. Dealing with Changes in Underlay Networks ..........15
4.4.4. Use of Groupings ...................................15
4.4.5. Cardinality and Directionality of Links ............16
4.4.6. Multihoming and Link Aggregation ...................16
4.4.7. Mapping Redundancy .................................16
4.4.8. Typing .............................................17
4.4.9. Representing the Same Device in Multiple Networks ..17
4.4.10. Supporting Client-Configured and
System-Controlled Network Topologies ..............18
4.4.11. Identifiers of String or URI Type .................19
5. Interactions with Other YANG Modules ...........................19
6. YANG Modules ...................................................20
6.1. Defining the Abstract Network: ietf-network ...............20
6.2. Creating Abstract Network Topology:
ietf-network-topology .....................................25
7. IANA Considerations ............................................32
8. Security Considerations ........................................33
9. References .....................................................35
9.1. Normative References ......................................35
9.2. Informative References ....................................36
Appendix A. Model Use Cases .......................................38
A.1. Fetching Topology from a Network Element ...................38
A.2. Modifying TE Topology Imported from an Optical Controller ..38
A.3. Annotating Topology for Local Computation ..................39
A.4. SDN Controller-Based Configuration of Overlays on Top of
Underlays ..................................................39
Appendix B. Companion YANG Data Models for Implementations Not
Compliant with NMDA ...................................39
B.1. YANG Module for Network State ..............................40
B.2. YANG Module for Network Topology State .....................45
Appendix C. An Example ............................................52
Acknowledgments ...................................................56
Contributors ......................................................56
Authors' Addresses ................................................57
This document introduces an abstract (base) YANG [RFC7950] data model [RFC3444] to represent networks and topologies. The data model is divided into two parts: The first part of the data model defines a network data model that enables the definition of network hierarchies, or network stacks (i.e., networks that are layered on top of each other) and maintenance of an inventory of nodes contained in a network. The second part of the data model augments the basic network data model with information to describe topology information. Specifically, it adds the concepts of "links" and "termination points" to describe how nodes in a network are connected to each other. Moreover, the data model introduces vertical layering relationships between networks that can be augmented to cover both network inventories and network/service topologies.
本文档介绍一个抽象（基本）YANG[RFC7950]数据模型[RFC3444]，用于表示网络和拓扑。数据模型分为两部分：数据模型的第一部分定义了一个网络数据模型，该模型支持定义网络层次结构或网络堆栈（即，分层在彼此之上的网络）和维护网络中包含的节点清单。数据模型的第二部分用描述拓扑信息的信息扩充了基本网络数据模型。具体而言，它添加了“链路”和“终止点”的概念，以描述网络中的节点如何相互连接。此外，数据模型还引入了网络之间的垂直分层关系，这些关系可以扩展，以涵盖网络清单和网络/服务拓扑。
Although it would be possible to combine both parts into a single data model, the separation facilitates integration of network topology and network inventory data models, because it allows network inventory information to be augmented separately, and without concern for topology, into the network data model.
虽然可以将这两个部分合并为一个数据模型，但这种分离有助于网络拓扑和网络资源清册数据模型的集成，因为它允许将网络资源清册信息单独扩充到网络数据模型中，而不必考虑拓扑。
The data model can be augmented to describe the specifics of particular types of networks and topologies. For example, an augmenting data model can provide network node information with attributes that are specific to a particular network type. Examples of augmenting models include data models for Layer 2 network topologies; Layer 3 network topologies such as unicast IGP, IS-IS [RFC1195], and OSPF [RFC2328]; traffic engineering (TE) data [RFC3209]; or any of the variety of transport and service topologies. Information specific to particular network types will be captured in separate, technology-specific data models.
可以对数据模型进行扩充，以描述特定类型网络和拓扑的细节。例如，扩充数据模型可以提供具有特定于特定网络类型的属性的网络节点信息。增强模型的示例包括第2层网络拓扑的数据模型；第3层网络拓扑，如单播IGP、IS-IS[RFC1195]和OSPF[RFC2328]；交通工程（TE）数据[RFC3209]；或任何一种传输和服务拓扑。特定于特定网络类型的信息将在单独的、特定于技术的数据模型中捕获。
The basic data models introduced in this document are generic in nature and can be applied to many network and service topologies and inventories. The data models allow applications to operate on an inventory or topology of any network at a generic level, where the specifics of particular inventory/topology types are not required. At the same time, where data specific to a network type comes into play and the data model is augmented, the instantiated data still adheres to the same structure and is represented in a consistent fashion. This also facilitates the representation of network hierarchies and dependencies between different network components and network types.
本文档中介绍的基本数据模型本质上是通用的，可以应用于许多网络和服务拓扑以及清单。数据模型允许应用程序在通用级别上对任何网络的资源清册或拓扑进行操作，其中不需要特定资源清册/拓扑类型的细节。同时，当特定于网络类型的数据发挥作用并且数据模型被扩充时，实例化的数据仍然遵循相同的结构并以一致的方式表示。这也有助于表示不同网络组件和网络类型之间的网络层次结构和依赖关系。
The abstract (base) network YANG module introduced in this document, entitled "ietf-network" (Section 6.1), contains a list of abstract network nodes and defines the concept of "network hierarchy" (network
本文件中介绍的名为“ietf网络”（第6.1节）的抽象（基本）网络模块包含抽象网络节点列表，并定义了“网络层次”（网络）的概念
stack). The abstract network node can be augmented in inventory and topology data models with inventory-specific and topology-specific attributes. The network hierarchy (stack) allows any given network to have one or more "supporting networks". The relationship between the base network data model, the inventory data models, and the topology data models is shown in Figure 1 (dotted lines in the figure denote possible augmentations to models defined in this document).
堆栈）。抽象网络节点可以在具有特定于库存和拓扑的属性的库存和拓扑数据模型中扩充。网络层次结构（堆栈）允许任何给定网络具有一个或多个“支持网络”。基本网络数据模型、库存数据模型和拓扑数据模型之间的关系如图1所示（图中的虚线表示对本文档中定义的模型的可能扩展）。
+------------------------+
| |
| Abstract Network Model |
| |
+------------------------+
|
+-------+-------+
| |
V V
+------------+ ..............
| Abstract | : Inventory :
| Topology | : Model(s) :
| Model | : :
+------------+ ''''''''''''''
|
+-------------+-------------+-------------+
| | | |
V V V V
............ ............ ............ ............
: L1 : : L2 : : L3 : : Service :
: Topology : : Topology : : Topology : : Topology :
: Model : : Model : : Model : : Model :
'''''''''''' '''''''''''' '''''''''''' ''''''''''''
+------------------------+
| |
| Abstract Network Model |
| |
+------------------------+
|
+-------+-------+
| |
V V
+------------+ ..............
| Abstract | : Inventory :
| Topology | : Model(s) :
| Model | : :
+------------+ ''''''''''''''
|
+-------------+-------------+-------------+
| | | |
V V V V
............ ............ ............ ............
: L1 : : L2 : : L3 : : Service :
: Topology : : Topology : : Topology : : Topology :
: Model : : Model : : Model : : Model :
'''''''''''' '''''''''''' '''''''''''' ''''''''''''
Figure 1: The Network Data Model Structure
图1：网络数据模型结构
The network-topology YANG module introduced in this document, entitled "ietf-network-topology" (Section 6.2), defines a generic topology data model at its most general level of abstraction. The module defines a topology graph and components from which it is composed: nodes, edges, and termination points. Nodes (from the "ietf-network" module) represent graph vertices and links represent graph edges. Nodes also contain termination points that anchor the links. A network can contain multiple topologies -- for example, topologies at different layers and overlay topologies. The data model therefore allows relationships between topologies, as well as dependencies between nodes and termination points across topologies, to be captured. An example of a topology stack is shown in Figure 2.
本文件中介绍的名为“ietf网络拓扑”的网络拓扑模块（第6.2节）在最一般的抽象层次上定义了通用拓扑数据模型。该模块定义了拓扑图和组成拓扑图的组件：节点、边和终止点。节点（来自“ietf网络”模块）表示图形顶点，链接表示图形边。节点还包含锚定链接的终止点。一个网络可以包含多个拓扑——例如，不同层的拓扑和重叠拓扑。因此，数据模型允许捕获拓扑之间的关系，以及跨拓扑的节点和端点之间的依赖关系。拓扑堆栈的示例如图2所示。
+---------------------------------------+
/ _[X1]_ "Service" /
/ _/ : \_ /
/ _/ : \_ /
/ _/ : \_ /
/ / : \ /
/ [X2]__________________[X3] /
+---------:--------------:------:-------+
: : :
+----:--------------:----:--------------+
/ : : : "L3" /
/ : : : /
/ : : : /
/ [Y1]_____________[Y2] /
/ * * * /
/ * * * /
+--------------*-------------*--*-------+
* * *
+--------*----------*----*--------------+
/ [Z1]_______________[Z2] "Optical" /
/ \_ * _/ /
/ \_ * _/ /
/ \_ * _/ /
/ \ * / /
/ [Z] /
+---------------------------------------+
+---------------------------------------+
/ _[X1]_ "Service" /
/ _/ : \_ /
/ _/ : \_ /
/ _/ : \_ /
/ / : \ /
/ [X2]__________________[X3] /
+---------:--------------:------:-------+
: : :
+----:--------------:----:--------------+
/ : : : "L3" /
/ : : : /
/ : : : /
/ [Y1]_____________[Y2] /
/ * * * /
/ * * * /
+--------------*-------------*--*-------+
* * *
+--------*----------*----*--------------+
/ [Z1]_______________[Z2] "Optical" /
/ \_ * _/ /
/ \_ * _/ /
/ \_ * _/ /
/ \ * / /
/ [Z] /
+---------------------------------------+
Figure 2: Topology Hierarchy (Stack) Example
图2：拓扑层次结构（堆栈）示例
Figure 2 shows three topology levels. At the top, the "Service" topology shows relationships between service entities, such as service functions in a service chain. The "L3" topology shows network elements at Layer 3 (IP), and the "Optical" topology shows network elements at Layer 1. Service functions in the "Service" topology are mapped onto network elements in the "L3" topology, which in turn are mapped onto network elements in the "Optical" topology. Two service functions (X1 and X3) are mapped onto a single L3 network element (Y2); this could happen, for example, if two service functions reside in the same Virtual Machine (VM) (or server) and share the same set of network interfaces. A single "L3" network element (Y2) is mapped onto two "Optical" network elements (Z2 and Z). This could happen, for example, if a single IP router attaches to multiple Reconfigurable Optical Add/Drop Multiplexers (ROADMs) in the optical domain.
图2显示了三个拓扑级别。在顶部，“服务”拓扑显示服务实体之间的关系，例如服务链中的服务功能。“L3”拓扑显示第3层（IP）的网络元素，“光学”拓扑显示第1层的网络元素。“服务”拓扑中的服务功能映射到“L3”拓扑中的网元上，而“L3”拓扑中的网元又映射到“光”拓扑中的网元上。将两个服务功能（X1和X3）映射到单个L3网元（Y2）；例如，如果两个服务功能驻留在同一虚拟机（VM）（或服务器）中并共享同一组网络接口，则可能会发生这种情况。单个“L3”网元（Y2）映射到两个“光学”网元（Z2和Z）。例如，如果单个IP路由器连接到光域中的多个可重构光分插复用器（ROADM），则可能发生这种情况。
Another example of a service topology stack is shown in Figure 3.
服务拓扑堆栈的另一个示例如图3所示。
VPN1 VPN2
+---------------------+ +---------------------+
/ [Y5]... / / [Z5]______[Z3] /
/ / \ : / / : \_ / : /
/ / \ : / / : \_ / : /
/ / \ : / / : \ / : /
/ [Y4]____[Y1] : / / : [Z2] : /
+------:-------:---:--+ +---:---------:-----:-+
: : : : : :
: : : : : :
: +-------:---:-----:------------:-----:-----+
: / [X1]__:___:___________[X2] : /
:/ / \_ : : _____/ / : /
: / \_ : _____/ / : /
/: / \: / / : /
/ : / [X5] / : /
/ : / __/ \__ / : /
/ : / ___/ \__ / : /
/ : / ___/ \ / : /
/ [X4]__________________[X3]..: /
+------------------------------------------+
L3 Topology
VPN1 VPN2
+---------------------+ +---------------------+
/ [Y5]... / / [Z5]______[Z3] /
/ / \ : / / : \_ / : /
/ / \ : / / : \_ / : /
/ / \ : / / : \ / : /
/ [Y4]____[Y1] : / / : [Z2] : /
+------:-------:---:--+ +---:---------:-----:-+
: : : : : :
: : : : : :
: +-------:---:-----:------------:-----:-----+
: / [X1]__:___:___________[X2] : /
:/ / \_ : : _____/ / : /
: / \_ : _____/ / : /
/: / \: / / : /
/ : / [X5] / : /
/ : / __/ \__ / : /
/ : / ___/ \__ / : /
/ : / ___/ \ / : /
/ [X4]__________________[X3]..: /
+------------------------------------------+
L3 Topology
Figure 3: Topology Hierarchy (Stack) Example
图3：拓扑层次结构（堆栈）示例
Figure 3 shows two VPN service topologies (VPN1 and VPN2) instantiated over a common L3 topology. Each VPN service topology is mapped onto a subset of nodes from the common L3 topology.
图3显示了在公共L3拓扑上实例化的两种VPN服务拓扑（VPN1和VPN2）。每个VPN服务拓扑都映射到来自公共L3拓扑的节点子集上。
There are multiple applications for such a data model. For example, within the context of Interface to the Routing System (I2RS), nodes within the network can use the data model to capture their understanding of the overall network topology and expose it to a network controller. A network controller can then use the instantiated topology data to compare and reconcile its own view of the network topology with that of the network elements that it controls. Alternatively, nodes within the network could propagate this understanding to compare and reconcile this understanding either among themselves or with the help of a controller. Beyond the network element and the immediate context of I2RS itself, a network controller might even use the data model to represent its view of the topology that it controls and expose it to applications north of itself. Further use cases where the data model can be applied are described in [USECASE-REQS].
这种数据模型有多种应用程序。例如，在路由系统接口（I2RS）的上下文中，网络中的节点可以使用数据模型来获取他们对整个网络拓扑的理解，并将其公开给网络控制器。然后，网络控制器可以使用实例化的拓扑数据，将其自己的网络拓扑视图与其控制的网络元素的视图进行比较和协调。或者，网络中的节点可以传播这种理解，以便在它们之间或在控制器的帮助下比较和协调这种理解。除了网络元素和I2RS本身的直接上下文之外，网络控制器甚至可能使用数据模型来表示其控制的拓扑视图，并将其公开给其北部的应用程序。[USECASE-REQS]中描述了可应用数据模型的其他用例。
In this data model, a network is categorized as either system controlled or not. If a network is system controlled, then it is automatically populated by the server and represents dynamically learned information that can be read from the operational state datastore. The data model can also be used to create or modify network topologies that might be associated with an inventory model or with an overlay network. Such a network is not system controlled; rather, it is configured by a client.
在此数据模型中，网络被分类为系统控制或非系统控制。如果网络由系统控制，那么它将由服务器自动填充，并表示可从运行状态数据存储读取的动态学习信息。数据模型还可用于创建或修改可能与资源清册模型或覆盖网络关联的网络拓扑。这种网络不是由系统控制的；相反，它是由客户机配置的。
The data model allows a network to refer to a supporting network, supporting nodes, supporting links, etc. The data model also allows the layering of a network that is configured on top of a network that is system controlled. This permits the configuration of overlay networks on top of networks that are discovered. Specifically, this data model is structured to support being implemented as part of the ephemeral datastore [RFC8342], the requirements for which are defined in Section 3 of [RFC8242]. This allows network topology data that is written, i.e., configured by a client and not system controlled, to refer to dynamically learned data that is controlled by the system, not configured by a client. A simple use case might involve creating an overlay network that is supported by the dynamically discovered IP-routed network topology. When an implementation places written data for this data model in the ephemeral datastore, such a network MAY refer to another network that is system controlled.
数据模型允许网络参考支持网络、支持节点、支持链路等。数据模型还允许在系统控制的网络上配置网络分层。这允许在发现的网络之上配置覆盖网络。具体而言，该数据模型的结构支持作为临时数据存储[RFC8342]的一部分实施，其要求在[RFC8242]第3节中定义。这允许写入的网络拓扑数据（即，由客户机配置而非系统控制的）引用由系统控制而非客户机配置的动态学习数据。一个简单的用例可能涉及创建由动态发现的IP路由网络拓扑支持的覆盖网络。当一个实现将该数据模型的写入数据放入临时数据存储中时，这样的网络可能会引用另一个系统控制的网络。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. A datastore maps to an instantiated YANG data tree (definition from [RFC8342]).
数据存储：存储和访问信息的概念性场所。例如，可以使用文件、数据库、闪存位置或其组合来实现数据存储。数据存储映射到实例化的数据树（来自[RFC8342]的定义）。
Data subtree: An instantiated data node and the data nodes that are hierarchically contained within it.
数据子树：一个实例化的数据节点和其中分层包含的数据节点。
IGP: Interior Gateway Protocol.
IGP：内部网关协议。
IS-IS: Intermediate System to Intermediate System.
IS-IS：中间系统至中间系统。
OSPF: Open Shortest Path First (a link-state routing protocol).
OSPF：开放最短路径优先（链路状态路由协议）。
SDN: Software-Defined Networking.
SDN：软件定义的网络。
URI: Uniform Resource Identifier.
URI：统一资源标识符。
VM: Virtual Machine.
虚拟机：虚拟机。
The abstract (base) network data model is defined in the "ietf-network" module. Its structure is shown in Figure 4. The notation syntax follows the syntax used in [RFC8340].
抽象（基本）网络数据模型在“ietf网络”模块中定义。其结构如图4所示。符号语法遵循[RFC8340]中使用的语法。
module: ietf-network
+--rw networks
+--rw network* [network-id]
+--rw network-id network-id
+--rw network-types
+--rw supporting-network* [network-ref]
| +--rw network-ref -> /networks/network/network-id
+--rw node* [node-id]
+--rw node-id node-id
+--rw supporting-node* [network-ref node-ref]
+--rw network-ref
| -> ../../../supporting-network/network-ref
+--rw node-ref -> /networks/network/node/node-id
module: ietf-network
+--rw networks
+--rw network* [network-id]
+--rw network-id network-id
+--rw network-types
+--rw supporting-network* [network-ref]
| +--rw network-ref -> /networks/network/network-id
+--rw node* [node-id]
+--rw node-id node-id
+--rw supporting-node* [network-ref node-ref]
+--rw network-ref
| -> ../../../supporting-network/network-ref
+--rw node-ref -> /networks/network/node/node-id
Figure 4: The Structure of the Abstract (Base) Network Data Model
图4：抽象（基本）网络数据模型的结构
The data model contains a container with a list of networks. Each network is captured in its own list entry, distinguished via a network-id.
数据模型包含一个包含网络列表的容器。每个网络都被捕获到自己的列表条目中，通过网络id进行区分。
A network has a certain type, such as L2, L3, OSPF, or IS-IS. A network can even have multiple types simultaneously. The type or types are captured underneath the container "network-types". In this model, it serves merely as an augmentation target; network-specific modules will later introduce new data nodes to represent new network types below this target, i.e., will insert them below "network-types" via YANG augmentation.
网络具有某种类型，如L2、L3、OSPF或IS-IS。一个网络甚至可以同时具有多种类型。在容器“网络类型”下捕获一个或多个类型。在这个模型中，它只是一个增强目标；特定于网络的模块稍后将引入新的数据节点，以表示低于该目标的新网络类型，即通过扩展将它们插入到“网络类型”下面。
When a network is of a certain type, it will contain a corresponding data node. Network types SHOULD always be represented using presence containers, not leafs of type "empty". This allows the representation of hierarchies of network subtypes within the instance information. For example, an instance of an OSPF network (which, at the same time, is a Layer 3 unicast IGP network) would contain underneath "network-types" another presence container "l3-unicast-igp-network", which in turn would contain a presence container "ospf-network". Actual examples of this pattern can be found in [RFC8346].
当网络属于某种类型时，它将包含相应的数据节点。网络类型应始终使用状态容器表示，而不是类型为“empty”的叶子。这允许在实例信息中表示网络子类型的层次结构。例如，OSPF网络的实例（同时是第3层单播IGP网络）将在“网络类型”下包含另一个存在容器“l3单播IGP网络”，该存在容器反过来将包含存在容器“OSPF网络”。此模式的实际示例可在[RFC8346]中找到。
A network can in turn be part of a hierarchy of networks, building on top of other networks. Any such networks are captured in the list "supporting-network". A supporting network is, in effect, an underlay network.
网络又可以是网络层次结构的一部分，建立在其他网络之上。任何此类网络都包含在“支持网络”列表中。支撑网络实际上是一个参考底图网络。
Furthermore, a network contains an inventory of nodes that are part of the network. The nodes of a network are captured in their own list. Each node is identified relative to its containing network by a node-id.
此外，网络包含作为网络一部分的节点的清单。网络的节点被捕获到它们自己的列表中。每个节点都通过节点id相对于其包含的网络进行标识。
It should be noted that a node does not exist independently of a network; instead, it is a part of the network that contains it. In cases where the same device or entity takes part in multiple networks, or at multiple layers of a networking stack, the same device or entity will be represented by multiple nodes, one for each network. In other words, the node represents an abstraction of the device for the particular network of which it is a part. To indicate that the same entity or device is part of multiple topologies or networks, it is possible to create one "physical" network with a list of nodes for each of the devices or entities. This (physical) network -- the nodes (entities) in that network -- can then be referred to as an underlay network and as nodes from the other (logical) networks and nodes, respectively. Note that the data model
应当注意的是，节点并不独立于网络而存在；相反，它是包含它的网络的一部分。在同一设备或实体参与多个网络或网络堆栈的多个层的情况下，同一设备或实体将由多个节点表示，每个网络一个节点。换言之，节点代表其所属的特定网络的设备的抽象。为了指示同一实体或设备是多个拓扑或网络的一部分，可以创建一个“物理”网络，其中包含每个设备或实体的节点列表。该（物理）网络——该网络中的节点（实体）——可以分别称为参考底图网络和来自其他（逻辑）网络和节点的节点。请注意，数据模型
allows for the definition of more than one underlay network (and node), allowing for simultaneous representation of layered network topologies and service topologies, and their physical instantiation.
允许定义多个参考底图网络（和节点），允许同时表示分层网络拓扑和服务拓扑及其物理实例化。
Similar to a network, a node can be supported by other nodes and map onto one or more other nodes in an underlay network. This is captured in the list "supporting-node". The resulting hierarchy of nodes also allows for the representation of device stacks, where a node at one level is supported by a set of nodes at an underlying level. For example:
与网络类似，节点可以由其他节点支持，并映射到参考底图网络中的一个或多个其他节点上。这在“支持节点”列表中捕获。由此产生的节点层次结构还允许表示设备堆栈，其中一个级别的节点由底层级别的一组节点支持。例如：
o a "router" node might be supported by a node representing a route processor and separate nodes for various line cards and service modules,
o “路由器”节点可能由代表路由处理器的节点和用于各种线路卡和服务模块的单独节点支持，
o a virtual router might be supported or hosted on a physical device represented by a separate node,
o 虚拟路由器可能支持或托管在由单独节点表示的物理设备上，
and so on.
等等
Network data of a network at a particular layer can come into being in one of two ways: (1) the network data is configured by client applications -- for example, in the case of overlay networks that are configured by an SDN Controller application, or (2) the network data is automatically controlled by the system, in the case of networks that can be discovered. It is possible for a configured (overlay) network to refer to a (discovered) underlay network.
特定层网络的网络数据可以通过以下两种方式之一形成：（1）网络数据由客户端应用程序配置——例如，在由SDN控制器应用程序配置的覆盖网络的情况下，或者（2）网络数据由系统自动控制，对于可以发现的网络。配置的（覆盖）网络可以引用（发现的）参考底图网络。
The revised datastore architecture [RFC8342] is used to account for those possibilities. Specifically, for each network, the origin of its data is indicated per the "origin" metadata [RFC7952] annotation (as defined in [RFC8342]) -- "intended" for data that was configured by a client application and "learned" for data that is discovered. Network data that is discovered is automatically populated as part of the operational state datastore. Network data that is configured is part of the configuration and intended datastores, respectively. Configured network data that is actually in effect is, in addition, reflected in the operational state datastore. Data in the operational state datastore will always have complete referential integrity. Should a configured data item (such as a node) have a dangling reference that refers to a non-existing data item (such as a supporting node), the configured data item will automatically be removed from the operational state datastore and thus only appear in the intended datastore. It will be up to the client application (such as an SDN Controller) to resolve the situation and ensure that the reference to the supporting resources is configured properly.
修改后的数据存储体系结构[RFC8342]用于说明这些可能性。具体地说，对于每个网络，其数据的来源根据“来源”元数据[RFC7952]注释（如[RFC8342]中所定义）来指示——对于由客户端应用程序配置的数据来说是“预期的”，对于发现的数据来说是“学习的”。发现的网络数据将作为操作状态数据存储的一部分自动填充。配置的网络数据分别是配置和预期数据存储的一部分。此外，实际有效的配置网络数据还反映在操作状态数据存储中。操作状态数据存储中的数据始终具有完整的引用完整性。如果配置的数据项（如节点）具有指向不存在的数据项（如支持节点）的悬挂引用，则配置的数据项将自动从操作状态数据存储中删除，因此仅出现在预期的数据存储中。由客户端应用程序（如SDN控制器）来解决这种情况，并确保正确配置对支持资源的引用。
The abstract (base) network topology data model is defined in the "ietf-network-topology" module. It builds on the network data model defined in the "ietf-network" module, augmenting it with links (defining how nodes are connected) and termination points (which anchor the links and are contained in nodes). The structure of the network topology module is shown in Figure 5. The notation syntax follows the syntax used in [RFC8340].
抽象（基本）网络拓扑数据模型在“ietf网络拓扑”模块中定义。它以“ietf网络”模块中定义的网络数据模型为基础，通过链路（定义节点的连接方式）和端点（锚定链路并包含在节点中）对其进行扩展。网络拓扑模块的结构如图5所示。符号语法遵循[RFC8340]中使用的语法。
module: ietf-network-topology
augment /nw:networks/nw:network:
+--rw link* [link-id]
+--rw link-id link-id
+--rw source
| +--rw source-node? -> ../../../nw:node/node-id
| +--rw source-tp? leafref
+--rw destination
| +--rw dest-node? -> ../../../nw:node/node-id
| +--rw dest-tp? leafref
+--rw supporting-link* [network-ref link-ref]
+--rw network-ref
| -> ../../../nw:supporting-network/network-ref
+--rw link-ref leafref
augment /nw:networks/nw:network/nw:node:
+--rw termination-point* [tp-id]
+--rw tp-id tp-id
+--rw supporting-termination-point*
[network-ref node-ref tp-ref]
+--rw network-ref
| -> ../../../nw:supporting-node/network-ref
+--rw node-ref
| -> ../../../nw:supporting-node/node-ref
+--rw tp-ref leafref
module: ietf-network-topology
augment /nw:networks/nw:network:
+--rw link* [link-id]
+--rw link-id link-id
+--rw source
| +--rw source-node? -> ../../../nw:node/node-id
| +--rw source-tp? leafref
+--rw destination
| +--rw dest-node? -> ../../../nw:node/node-id
| +--rw dest-tp? leafref
+--rw supporting-link* [network-ref link-ref]
+--rw network-ref
| -> ../../../nw:supporting-network/network-ref
+--rw link-ref leafref
augment /nw:networks/nw:network/nw:node:
+--rw termination-point* [tp-id]
+--rw tp-id tp-id
+--rw supporting-termination-point*
[network-ref node-ref tp-ref]
+--rw network-ref
| -> ../../../nw:supporting-node/network-ref
+--rw node-ref
| -> ../../../nw:supporting-node/node-ref
+--rw tp-ref leafref
Figure 5: The Structure of the Abstract (Base) Network Topology Data Model
图5：抽象（基本）网络拓扑数据模型的结构
A node has a list of termination points that are used to terminate links. An example of a termination point might be a physical or logical port or, more generally, an interface.
节点具有用于终止链接的终止点列表。终止点的示例可能是物理或逻辑端口，或者更一般地说，是接口。
Like a node, a termination point can in turn be supported by an underlying termination point, contained in the supporting node of the underlay network.
与节点一样，终止点也可以由包含在参考底图网络的支持节点中的基础终止点来支持。
A link is identified by a link-id that uniquely identifies the link within a given topology. Links are point-to-point and unidirectional. Accordingly, a link contains a source and a destination. Both source and destination reference a corresponding node, as well as a termination point on that node. Similar to a node, a link can map onto one or more links (which are terminated by the corresponding underlay termination points) in an underlay topology. This is captured in the list "supporting-link".
链接由唯一标识给定拓扑中的链接的链接id标识。链接是点对点和单向的。因此，链路包含源和目的地。源和目标都引用相应的节点，以及该节点上的终止点。与节点类似，链接可以映射到参考底图拓扑中的一个或多个链接（由相应的参考底图终止点终止）。这可在“支持链接”列表中找到。
In order to derive a data model for a specific type of network, the base data model can be extended. This can be done roughly as follows: a new YANG module for the new network type is introduced. In this module, a number of augmentations are defined against the "ietf-network" and "ietf-network-topology" modules.
为了推导特定类型网络的数据模型，可以扩展基本数据模型。这可以大致做到以下几点：为新的网络类型引入了一个新的YANG模块。在本模块中，针对“ietf网络”和“ietf网络拓扑”模块定义了许多增强功能。
We start with augmentations against the "ietf-network" module. First, a new network type needs to be defined; this is done by defining a presence container that represents the new network type. The new network type is inserted, by means of augmentation, below the network-types container. Subsequently, data nodes for any node parameters that are specific to a network type are defined and augmented into the node list. The new data nodes can be defined as conditional ("when") on the presence of the corresponding network type in the containing network. In cases where there are any requirements or restrictions in terms of network hierarchies, such as when a network of a new network type requires a specific type of underlay network, it is possible to define corresponding constraints as well and augment the supporting-network list accordingly. However, care should be taken to avoid excessive definitions of constraints.
我们从增强“ietf网络”模块开始。首先，需要定义一种新的网络类型；这是通过定义表示新网络类型的状态容器来实现的。新的网络类型通过扩充的方式插入到网络类型容器下面。随后，定义特定于网络类型的任何节点参数的数据节点，并将其扩充到节点列表中。新数据节点可以定义为在包含网络中存在相应网络类型的条件（“何时”）。在网络层次结构方面存在任何要求或限制的情况下，例如当新网络类型的网络需要特定类型的参考底图网络时，也可以定义相应的约束并相应地增加支持网络列表。但是，应注意避免过度定义约束条件。
Subsequently, augmentations are defined against the "ietf-network-topology" module. Data nodes are defined for link parameters, as well as termination point parameters, that are specific to the new network type. Those data nodes are inserted via augmentation into the link and termination-point lists, respectively. Again, data nodes can be defined as conditional on the presence of the corresponding network type in the containing network, by adding a corresponding "when" statement.
随后，针对“ietf网络拓扑”模块定义了增强。数据节点是为特定于新网络类型的链路参数以及终止点参数定义的。这些数据节点分别通过扩充插入到链路和终止点列表中。同样，通过添加相应的“when”语句，可以将数据节点定义为在包含网络中存在相应网络类型的条件。
It is possible, but not required, to group data nodes for a given network type under a dedicated container. Doing so introduces additional structure but lengthens data node path names.
可以（但不是必需）将给定网络类型的数据节点分组到专用容器下。这样做会引入额外的结构，但会延长数据节点路径名。
In cases where a hierarchy of network types is defined, augmentations can in turn be applied against augmenting modules, with the module of a network whose type is more specific augmenting the module of a network whose type is more general.
在定义了网络类型层次结构的情况下，可以反过来对扩充模块应用扩充，其中类型更具体的网络模块扩充类型更一般的网络模块。
Rather than maintaining lists in separate containers, the data model is kept relatively flat in terms of its containment structure. Lists of nodes, links, termination points, and supporting nodes; supporting links; and supporting termination points are not kept in separate containers. Therefore, path identifiers that are used to refer to specific nodes -- in management operations or in specifications of constraints -- can remain relatively compact. Of course, this means that there is no separate structure in instance information that separates elements of different lists from one another. Such a structure is semantically not required, but it might provide enhanced "human readability" in some cases.
数据模型没有在单独的容器中维护列表，而是在其包含结构方面保持相对平坦。节点、链路、终止点和支持节点的列表；配套环节；支撑端接点不应存放在单独的容器中。因此，在管理操作或约束规范中用于引用特定节点的路径标识符可以保持相对紧凑。当然，这意味着实例信息中没有将不同列表的元素彼此分离的单独结构。这种结构在语义上是不需要的，但在某些情况下，它可能提供增强的“人类可读性”。
To minimize assumptions regarding what a particular entity might actually represent, mappings between networks, nodes, links, and termination points are kept strictly generic. For example, no assumptions are made regarding whether a termination point actually refers to an interface or whether a node refers to a specific "system" or device; the data model at this generic level makes no provisions for these.
为了尽量减少关于特定实体可能实际表示的内容的假设，网络、节点、链路和端点之间的映射保持严格的通用性。例如，未对终端点是否实际指接口或节点是否指特定的“系统”或设备进行假设；此通用级别的数据模型没有对这些进行规定。
Where additional specifics about mappings between upper and lower layers are required, the information can be captured in augmenting modules. For example, to express that a termination point in a particular network type maps to an interface, an augmenting module can introduce an augmentation to the termination point. The augmentation introduces a leaf of type "interface-ref". That leaf references the corresponding interface [RFC8343]. Similarly, if a node maps to a particular device or network element, an augmenting module can augment the node data with a leaf that references the network element.
如果需要关于上层和下层之间映射的其他细节，可以在增强模块中捕获信息。例如，为了表示特定网络类型中的终结点映射到接口，扩充模块可以向终结点引入扩充。扩展引入了一个类型为“interface ref”的叶。该叶引用相应的接口[RFC8343]。类似地，如果节点映射到特定设备或网元，则扩充模块可以使用引用该网元的叶来扩充节点数据。
It is possible for links at one level of a hierarchy to map to multiple links at another level of the hierarchy. For example, a VPN topology might model VPN tunnels as links. Where a VPN tunnel maps to a path that is composed of a chain of several links, the link will contain a list of those supporting links. Likewise, it is possible for a link at one level of a hierarchy to aggregate a bundle of links at another level of the hierarchy.
层次结构的一个级别上的链接可以映射到层次结构的另一个级别上的多个链接。例如，VPN拓扑可以将VPN隧道建模为链接。当VPN隧道映射到由多个链接链组成的路径时，该链接将包含这些支持链接的列表。同样，层次结构的一个级别上的链接也可以聚合层次结构的另一个级别上的链接束。
It is possible for a network to undergo churn even as other networks are layered on top of it. When a supporting node, link, or termination point is deleted, the supporting leafrefs in the overlay will be left dangling. To allow for this possibility, the data model makes use of the "require-instance" construct of YANG 1.1 [RFC7950].
一个网络有可能受到搅动，即使其他网络是分层的。删除支撑节点、链接或终止点时，覆盖中的支撑叶参照将悬空。为了考虑这种可能性，数据模型使用了YANG 1.1[RFC7950]的“require instance”构造。
A dangling leafref of a configured object leaves the corresponding instance in a state in which it lacks referential integrity, effectively rendering it nonoperational. Any corresponding object instance is therefore removed from the operational state datastore until the situation has been resolved, i.e., until either (1) the supporting object is added to the operational state datastore or (2) the instance is reconfigured to refer to another object that is actually reflected in the operational state datastore. It will remain part of the intended datastore.
配置对象的悬空leafref使相应实例处于缺乏引用完整性的状态，从而使其无法运行。因此，将从运行状态数据存储中删除任何相应的对象实例，直到解决了问题为止，即，直到（1）支持对象添加到运行状态数据存储或（2）实例重新配置为引用实际反映在运行状态数据存储中的另一个对象为止。它将仍然是预期数据存储的一部分。
It is the responsibility of the application maintaining the overlay to deal with the possibility of churn in the underlay network. When a server receives a request to configure an overlay network, it SHOULD validate whether supporting nodes / links / termination points refer to nodes in the underlay that actually exist, i.e., verify that the nodes are reflected in the operational state datastore. Configuration requests in which supporting nodes / links / termination points refer to objects currently not in existence SHOULD be rejected. It is the responsibility of the application to update the overlay when a supporting node / link / termination point is deleted at a later point in time. For this purpose, an application might subscribe to updates when changes to the underlay occur -- for example, using mechanisms defined in [YANG-Push].
维护覆盖的应用程序负责处理底层网络中可能出现的搅动。当服务器收到配置覆盖网络的请求时，应验证支持节点/链路/终止点是否指参考底图中实际存在的节点，即验证节点是否反映在运行状态数据存储中。支持节点/链路/终止点引用当前不存在的对象的配置请求应被拒绝。当支持节点/链路/终止点在稍后的时间点被删除时，应用程序负责更新覆盖。为此，应用程序可能会在参考底图发生更改时订阅更新，例如，使用[Push]中定义的机制。
The data model makes use of groupings instead of simply defining data nodes "inline". This makes it easier to include the corresponding data nodes in notifications, which then do not need to respecify each data node that is to be included. The trade-off is that it makes the specification of constraints more complex, because constraints involving data nodes outside the grouping need to be specified in
数据模型使用分组，而不是简单地“内联”定义数据节点。这使得在通知中包含相应的数据节点变得更容易，这样就不需要重新指定要包含的每个数据节点。取舍是，它使约束的规范更加复杂，因为需要在中指定涉及分组之外的数据节点的约束
conjunction with a "uses" statement where the grouping is applied. This also means that constraints and XML Path Language (XPath) statements need to be specified in such a way that they navigate "down" first and select entire sets of nodes, as opposed to being able to simply specify them against individual data nodes.
与应用分组的“uses”语句连用。这也意味着约束和XML路径语言（XPath）语句需要以这样的方式指定，即它们首先“向下”导航并选择整个节点集，而不是简单地针对单个数据节点指定它们。
The topology data model includes links that are point-to-point and unidirectional. It does not directly support multipoint and bidirectional links. Although this may appear as a limitation, the decision to do so keeps the data model simple and generic, and it allows it to be very easily subjected to applications that make use of graph algorithms. Bidirectional connections can be represented through pairs of unidirectional links. Multipoint networks can be represented through pseudonodes (similar to IS-IS, for example). By introducing hierarchies of nodes with nodes at one level mapping onto a set of other nodes at another level and by introducing new links for nodes at that level, topologies with connections representing non-point-to-point communication patterns can be represented.
拓扑数据模型包括点对点和单向链接。它不直接支持多点和双向链路。尽管这似乎是一个限制，但这样做的决定保持了数据模型的简单性和通用性，并且允许它非常容易地应用于使用图形算法的应用程序。双向连接可以通过成对的单向链路来表示。多点网络可以通过伪节点来表示（例如，类似于IS-IS）。通过引入节点的层次结构，其中一个级别的节点映射到另一个级别的一组其他节点上，并通过为该级别的节点引入新链接，可以表示具有代表非点对点通信模式的连接的拓扑。
Links are terminated by a single termination point, not sets of termination points. Connections involving multihoming or link aggregation schemes need to be represented using multiple point-to-point links and then defining a link at a higher layer that is supported by those individual links.
链路由单个终止点终止，而不是由多组终止点终止。涉及多归属或链路聚合方案的连接需要使用多个点到点链路来表示，然后在这些链路支持的更高层定义链路。
In a hierarchy of networks, there are nodes mapping to nodes, links mapping to links, and termination points mapping to termination points. Some of this information is redundant. Specifically, if the mapping of a link to one or more other links is known and the termination points of each link are known, the mapping information for the termination points can be derived via transitive closure and does not have to be explicitly configured. Nonetheless, in order to not constrain applications regarding which mappings they want to configure and which should be derived, the data model provides the option to configure this information explicitly. The data model includes integrity constraints to allow for validating for consistency.
在网络层次结构中，存在映射到节点的节点、映射到链接的链接和映射到终止点的终止点。有些信息是多余的。具体地说，如果链路到一个或多个其他链路的映射是已知的，并且每个链路的终止点是已知的，则终止点的映射信息可以通过传递闭包导出，并且不必显式配置。尽管如此，为了不限制应用程序要配置哪些映射以及应该派生哪些映射，数据模型提供了显式配置此信息的选项。数据模型包括完整性约束，以允许验证一致性。
A network's network types are represented using a container that contains a data node for each of its network types. A network can encompass several types of networks simultaneously; hence, a container is used instead of a case construct, with each network type in turn represented by a dedicated presence container. The reason for not simply using an empty leaf, or (even more simply) even doing away with the network container and just using a leaf-list of "network-type" instead, is to be able to represent "class hierarchies" of network types, with one network type "refining" the other. Containers specific to a network type are to be defined in the network-specific modules, augmenting the network-types container.
网络的网络类型使用一个容器表示，该容器包含其每个网络类型的数据节点。一个网络可以同时包含几种类型的网络；因此，使用容器代替case构造，每个网络类型依次由专用的存在容器表示。不简单地使用空叶，或者（更简单地说）甚至不使用网络容器而只使用“网络类型”的叶列表的原因是能够表示网络类型的“类层次结构”，其中一种网络类型“细化”另一种。特定于网络类型的容器将在特定于网络的模块中定义，以扩充网络类型容器。
One common requirement concerns the ability to indicate that the same device can be part of multiple networks and topologies. However, the data model defines a node as relative to the network that contains it. The same node cannot be part of multiple topologies. In many cases, a node will be the abstraction of a particular device in a network. To reflect that the same device is part of multiple topologies, the following approach might be chosen: a new type of network to represent a "physical" (or "device") network is introduced, with nodes representing devices. This network forms an underlay network for logical networks above it, with nodes of the logical network mapping onto nodes in the physical network.
一个常见的要求是能够指示同一设备可以是多个网络和拓扑的一部分。但是，数据模型将节点定义为相对于包含它的网络的节点。同一节点不能是多个拓扑的一部分。在许多情况下，节点将是网络中特定设备的抽象。为了反映同一设备是多个拓扑的一部分，可以选择以下方法：引入一种新型网络来表示“物理”（或“设备”）网络，节点表示设备。该网络为其上方的逻辑网络形成一个底层网络，逻辑网络的节点映射到物理网络中的节点。
This scenario is depicted in Figure 6. This figure depicts three networks with two nodes each. A physical network ("P" in the figure) consists of an inventory of two nodes (D1 and D2), each representing a device. A second network, X, has a third network, Y, as its underlay. Both X and Y also have the physical network (P) as their underlay. X1 has both Y1 and D1 as underlay nodes, while Y1 has D1 as its underlay node. Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as its underlay node. The fact that X1 and Y1 are both instantiated on the same physical node (D1) can be easily seen.
此场景如图6所示。此图描述了三个网络，每个网络有两个节点。物理网络（图中的“P”）由两个节点（D1和D2）组成，每个节点代表一个设备。第二个网络X具有第三个网络Y作为其参考底图。X和Y也将物理网络（P）作为其参考底图。X1将Y1和D1都作为参考底图节点，而Y1将D1作为其参考底图节点。同样，X2将Y2和D2都作为参考底图节点，而Y2将D2作为其参考底图节点。X1和Y1都在同一物理节点（D1）上实例化的事实很容易看出。
+---------------------+
/ [X1]____[X2] / X(Service Overlay)
+----:--:----:--------+
..: :..: :
........: ....: : :....
+-----:-------------:--+ : :...
/ [Y1]____[Y2]....: / :.. :
+------|-------|-------+ :.. :...
Y(L3) | +---------------------:-----+ :
| +----:----|-:----------+
+------------------------/---[D1] [D2] /
+----------------------+
P (Physical Network)
+---------------------+
/ [X1]____[X2] / X(Service Overlay)
+----:--:----:--------+
..: :..: :
........: ....: : :....
+-----:-------------:--+ : :...
/ [Y1]____[Y2]....: / :.. :
+------|-------|-------+ :.. :...
Y(L3) | +---------------------:-----+ :
| +----:----|-:----------+
+------------------------/---[D1] [D2] /
+----------------------+
P (Physical Network)
Figure 6: Topology Hierarchy Example - Multiple Underlays
图6：拓扑层次结构示例-多个参考底图
In the case of a physical network, nodes represent physical devices and termination points represent physical ports. It should be noted that it is also possible to augment the data model for a physical network type, defining augmentations that have nodes reference system information and termination points reference physical interfaces, in order to provide a bridge between network and device models.
对于物理网络，节点表示物理设备，终端点表示物理端口。应当注意，还可以扩充物理网络类型的数据模型，定义具有节点参考系统信息和端点参考物理接口的扩充，以便在网络和设备模型之间提供桥梁。
4.4.10. Supporting Client-Configured and System-Controlled Network Topologies
4.4.10. 支持客户端配置和系统控制的网络拓扑
YANG requires data nodes to be designated as either configuration data ("config true") or operational data ("config false"), but not both, yet it is important to have all network information, including vertical cross-network dependencies, captured in one coherent data model. In most cases, network topology information about a network is discovered; the topology is considered a property of the network that is reflected in the data model. That said, certain types of topologies need to also be configurable by an application, e.g., in the case of overlay topologies.
YANG要求将数据节点指定为配置数据（“config true”）或操作数据（“config false”），但不能同时指定为两者，但重要的是在一个一致的数据模型中捕获所有网络信息，包括垂直跨网络相关性。在大多数情况下，会发现有关网络的网络拓扑信息；拓扑被视为反映在数据模型中的网络属性。也就是说，某些类型的拓扑也需要由应用程序配置，例如，在覆盖拓扑的情况下。
The YANG data model for network topologies designates all data as "config true". The distinction between data that is actually configured and data that is in effect, including network data that is discovered, is provided through the datastores introduced as part of the Network Management Datastore Architecture (NMDA) [RFC8342]. Network topology data that is discovered is automatically populated as part of the operational state datastore, i.e., <operational>. It is "system controlled". Network topology that is configured is instantiated as part of a configuration datastore, e.g., <intended>. Only when it has actually taken effect will it also be instantiated as part of the operational state datastore, i.e., <operational>.
网络拓扑的YANG数据模型将所有数据指定为“config true”。通过作为网络管理数据存储体系结构（NMDA）一部分引入的数据存储提供实际配置的数据与有效数据（包括发现的网络数据）之间的区别[RFC8342]。发现的网络拓扑数据将自动填充为操作状态数据存储的一部分，即<operation>。它是“系统控制的”。配置的网络拓扑被实例化为配置数据存储的一部分，例如，<designed>。只有当它实际生效时，它才会被实例化为操作状态数据存储的一部分，即<operational>。
In general, a configured network topology will refer to an underlay topology and include layering information, such as the supporting node(s) underlying a node, supporting link(s) underlying a link, and supporting termination point(s) underlying a termination point. The supporting objects must be instantiated in the operational state datastore in order for the dependent overlay object to be reflected in the operational state datastore. Should a configured data item (such as a node) have a dangling reference that refers to a nonexistent data item (such as a supporting node), the configured data item will automatically be removed from <operational> and show up only in <intended>. It will be up to the client application to resolve the situation and ensure that the reference to the supporting resources is configured properly.
通常，已配置的网络拓扑将参考参考底图拓扑，并包括分层信息，例如节点下方的支持节点、链接下方的支持链路以及终止点下方的支持终止点。支持对象必须在操作状态数据存储中实例化，以便依赖覆盖对象反映在操作状态数据存储中。如果配置的数据项（如节点）具有指向不存在的数据项（如支持节点）的悬挂引用，则配置的数据项将自动从<operational>中删除，并仅显示在<designed>中。由客户端应用程序来解决这种情况，并确保正确配置对支持资源的引用。
For each network, the origin of its data is indicated per the "origin" metadata [RFC7952] annotation defined in [RFC8342]. In general, the origin of discovered network data is "learned"; the origin of configured network data is "intended".
对于每个网络，其数据的来源根据[RFC8342]中定义的“来源”元数据[RFC7952]注释指示。一般来说，发现的网络数据的来源是“已知的”；配置的网络数据的来源是“预期的”。
The current data model defines identifiers of nodes, networks, links, and termination points as URIs. Alternatively, they could have been defined as strings.
当前数据模型将节点、网络、链路和终止点的标识符定义为URI。或者，它们可以被定义为字符串。
The case for strings is that they will be easier to implement. The reason for choosing URIs is that the topology / node / termination point exists in a larger context; hence, it is useful to be able to correlate identifiers across systems. Although strings -- being the universal data type -- are easier for human beings, they also muddle things. What typically happens is that strings have some structure that is magically assigned, and the knowledge of this structure has to be communicated to each system working with the data. A URI makes the structure explicit and also attaches additional semantics: the URI, unlike a free-form string, can be fed into a URI resolver, which can point to additional resources associated with the URI. This property is important when the topology data is integrated into a larger and more complex system.
字符串的情况是它们更容易实现。选择URI的原因是拓扑/节点/终止点存在于更大的上下文中；因此，能够跨系统关联标识符是很有用的。虽然字符串作为通用数据类型对人类来说更容易，但它们也会把事情弄得一团糟。通常情况下，字符串具有某种神奇分配的结构，并且必须将此结构的知识传达给处理数据的每个系统。URI使结构显式，并附加额外的语义：与自由格式字符串不同，URI可以馈送到URI解析器中，该解析器可以指向与URI相关联的其他资源。当拓扑数据集成到更大、更复杂的系统中时，此属性非常重要。
The data model makes use of data types that have been defined in [RFC6991].
数据模型使用[RFC6991]中定义的数据类型。
This is a protocol-independent YANG data model with topology information. It is separate from, and not linked with, data models that are used to configure routing protocols or routing information. This includes, for example, the "ietf-routing" YANG module [RFC8022].
这是一个具有拓扑信息的独立于协议的YANG数据模型。它独立于用于配置路由协议或路由信息的数据模型，而不是与之链接。例如，这包括“ietf路由”模块[RFC8022]。
The data model obeys the requirements for the ephemeral state as specified in [RFC8242]. For ephemeral topology data that is system controlled, the process tasked with maintaining topology information will load information from the routing process (such as OSPF) into the operational state datastore without relying on a configuration datastore.
数据模型符合[RFC8242]中规定的短暂状态要求。对于系统控制的临时拓扑数据，负责维护拓扑信息的进程将把信息从路由进程（如OSPF）加载到操作状态数据存储中，而不依赖于配置数据存储。
<CODE BEGINS> file "ietf-network@2018-02-26.yang"
<CODE BEGINS> file "ietf-network@2018-02-26.yang"
module ietf-network {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network";
prefix nw;
module ietf-network {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network";
prefix nw;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
organization "IETF I2RS (Interface to the Routing System) Working Group";
组织“IETF I2RS（路由系统接口）工作组”；
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
description "This module defines a common base data model for a collection of nodes in a network. Node definitions are further used in network topologies and inventories.
description“此模块为网络中的节点集合定义公共基础数据模型。节点定义在网络拓扑和资源清册中进一步使用。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2018 IETF信托基金和被确定为代码作者的人员。版权所有。
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 Simplified 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).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8345;
see the RFC itself for full legal notices.";
This version of this YANG module is part of RFC 8345;
see the RFC itself for full legal notices.";
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
typedef node-id {
type inet:uri;
description
"Identifier for a node. The precise structure of the node-id
will be up to the implementation. For example, some
implementations MAY pick a URI that includes the network-id
as part of the path. The identifier SHOULD be chosen
such that the same node in a real network topology will
always be identified through the same identifier, even if
the data model is instantiated in separate datastores. An
implementation MAY choose to capture semantics in the
identifier -- for example, to indicate the type of node.";
}
typedef node-id {
type inet:uri;
description
"Identifier for a node. The precise structure of the node-id
will be up to the implementation. For example, some
implementations MAY pick a URI that includes the network-id
as part of the path. The identifier SHOULD be chosen
such that the same node in a real network topology will
always be identified through the same identifier, even if
the data model is instantiated in separate datastores. An
implementation MAY choose to capture semantics in the
identifier -- for example, to indicate the type of node.";
}
typedef network-id {
type inet:uri;
description
"Identifier for a network. The precise structure of the
network-id will be up to the implementation. The identifier
SHOULD be chosen such that the same network will always be
identified through the same identifier, even if the data model
is instantiated in separate datastores. An implementation MAY
choose to capture semantics in the identifier -- for example,
to indicate the type of network.";
}
typedef network-id {
type inet:uri;
description
"Identifier for a network. The precise structure of the
network-id will be up to the implementation. The identifier
SHOULD be chosen such that the same network will always be
identified through the same identifier, even if the data model
is instantiated in separate datastores. An implementation MAY
choose to capture semantics in the identifier -- for example,
to indicate the type of network.";
}
grouping network-ref {
description
"Contains the information necessary to reference a network --
for example, an underlay network.";
leaf network-ref {
type leafref {
path "/nw:networks/nw:network/nw:network-id";
require-instance false;
}
description
"Used to reference a network -- for example, an underlay
network.";
}
}
grouping network-ref {
description
"Contains the information necessary to reference a network --
for example, an underlay network.";
leaf network-ref {
type leafref {
path "/nw:networks/nw:network/nw:network-id";
require-instance false;
}
description
"Used to reference a network -- for example, an underlay
network.";
}
}
grouping node-ref {
description
"Contains the information necessary to reference a node.";
leaf node-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../"+
"network-ref]/nw:node/nw:node-id";
require-instance false;
}
description
"Used to reference a node.
Nodes are identified relative to the network that
contains them.";
}
uses network-ref;
}
grouping node-ref {
description
"Contains the information necessary to reference a node.";
leaf node-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../"+
"network-ref]/nw:node/nw:node-id";
require-instance false;
}
description
"Used to reference a node.
Nodes are identified relative to the network that
contains them.";
}
uses network-ref;
}
container networks {
description
"Serves as a top-level container for a list of networks.";
list network {
key "network-id";
description
"Describes a network.
A network typically contains an inventory of nodes,
topological information (augmented through the
network-topology data model), and layering information.";
leaf network-id {
type network-id;
description
"Identifies a network.";
}
container network-types {
description
"Serves as an augmentation target.
The network type is indicated through corresponding
presence containers augmented into this container.";
}
list supporting-network {
key "network-ref";
description
"An underlay network, used to represent layered network
topologies.";
leaf network-ref {
type leafref {
path "/nw:networks/nw:network/nw:network-id";
require-instance false;
}
description
"References the underlay network.";
}
}
container networks {
description
"Serves as a top-level container for a list of networks.";
list network {
key "network-id";
description
"Describes a network.
A network typically contains an inventory of nodes,
topological information (augmented through the
network-topology data model), and layering information.";
leaf network-id {
type network-id;
description
"Identifies a network.";
}
container network-types {
description
"Serves as an augmentation target.
The network type is indicated through corresponding
presence containers augmented into this container.";
}
list supporting-network {
key "network-ref";
description
"An underlay network, used to represent layered network
topologies.";
leaf network-ref {
type leafref {
path "/nw:networks/nw:network/nw:network-id";
require-instance false;
}
description
"References the underlay network.";
}
}
list node {
key "node-id";
description
"The inventory of nodes of this network.";
leaf node-id {
type node-id;
description
"Uniquely identifies a node within the containing
network.";
}
list supporting-node {
key "network-ref node-ref";
description
"Represents another node that is in an underlay network
and that supports this node. Used to represent layering
structure.";
leaf network-ref {
type leafref {
path "../../../nw:supporting-network/nw:network-ref";
require-instance false;
}
description
"References the underlay network of which the
underlay node is a part.";
}
leaf node-ref {
type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id";
require-instance false;
}
description
"References the underlay node itself.";
}
}
}
}
}
}
list node {
key "node-id";
description
"The inventory of nodes of this network.";
leaf node-id {
type node-id;
description
"Uniquely identifies a node within the containing
network.";
}
list supporting-node {
key "network-ref node-ref";
description
"Represents another node that is in an underlay network
and that supports this node. Used to represent layering
structure.";
leaf network-ref {
type leafref {
path "../../../nw:supporting-network/nw:network-ref";
require-instance false;
}
description
"References the underlay network of which the
underlay node is a part.";
}
leaf node-ref {
type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id";
require-instance false;
}
description
"References the underlay node itself.";
}
}
}
}
}
}
<CODE ENDS>
<代码结束>
<CODE BEGINS> file "ietf-network-topology@2018-02-26.yang"
<CODE BEGINS> file "ietf-network-topology@2018-02-26.yang"
module ietf-network-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
prefix nt;
module ietf-network-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
prefix nt;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
organization "IETF I2RS (Interface to the Routing System) Working Group";
组织“IETF I2RS（路由系统接口）工作组”；
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
description "This module defines a common base model for a network topology, augmenting the base network data model with links to connect nodes, as well as termination points to terminate links on nodes.
description“此模块定义网络拓扑的公共基础模型，通过连接节点的链接以及终止节点上链接的终止点来扩展基础网络数据模型。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2018 IETF信托基金和被确定为代码作者的人员。版权所有。
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 Simplified 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).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8345;
see the RFC itself for full legal notices.";
This version of this YANG module is part of RFC 8345;
see the RFC itself for full legal notices.";
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
typedef link-id {
type inet:uri;
description
"An identifier for a link in a topology. The precise
structure of the link-id will be up to the implementation.
The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the
same identifier, even if the data model is instantiated in
separate datastores. An implementation MAY choose to capture
semantics in the identifier -- for example, to indicate the
type of link and/or the type of topology of which the link is
a part.";
}
typedef link-id {
type inet:uri;
description
"An identifier for a link in a topology. The precise
structure of the link-id will be up to the implementation.
The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the
same identifier, even if the data model is instantiated in
separate datastores. An implementation MAY choose to capture
semantics in the identifier -- for example, to indicate the
type of link and/or the type of topology of which the link is
a part.";
}
typedef tp-id {
type inet:uri;
description
"An identifier for termination points on a node. The precise
structure of the tp-id will be up to the implementation.
The identifier SHOULD be chosen such that the same termination
point in a real network topology will always be identified
through the same identifier, even if the data model is
typedef tp-id {
type inet:uri;
description
"An identifier for termination points on a node. The precise
structure of the tp-id will be up to the implementation.
The identifier SHOULD be chosen such that the same termination
point in a real network topology will always be identified
through the same identifier, even if the data model is
instantiated in separate datastores. An implementation MAY
choose to capture semantics in the identifier -- for example,
to indicate the type of termination point and/or the type of
node that contains the termination point.";
}
instantiated in separate datastores. An implementation MAY
choose to capture semantics in the identifier -- for example,
to indicate the type of termination point and/or the type of
node that contains the termination point.";
}
grouping link-ref {
description
"This grouping can be used to reference a link in a specific
network. Although it is not used in this module, it is
defined here for the convenience of augmenting modules.";
leaf link-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../"+
"network-ref]/nt:link/nt:link-id";
require-instance false;
}
description
"A type for an absolute reference to a link instance.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw:network-ref;
}
grouping link-ref {
description
"This grouping can be used to reference a link in a specific
network. Although it is not used in this module, it is
defined here for the convenience of augmenting modules.";
leaf link-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../"+
"network-ref]/nt:link/nt:link-id";
require-instance false;
}
description
"A type for an absolute reference to a link instance.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw:network-ref;
}
grouping tp-ref {
description
"This grouping can be used to reference a termination point
in a specific node. Although it is not used in this module,
it is defined here for the convenience of augmenting
modules.";
leaf tp-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../"+
"network-ref]/nw:node[nw:node-id=current()/../"+
"node-ref]/nt:termination-point/nt:tp-id";
require-instance false;
}
description
"A type for an absolute reference to a termination point.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw:node-ref;
}
grouping tp-ref {
description
"This grouping can be used to reference a termination point
in a specific node. Although it is not used in this module,
it is defined here for the convenience of augmenting
modules.";
leaf tp-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../"+
"network-ref]/nw:node[nw:node-id=current()/../"+
"node-ref]/nt:termination-point/nt:tp-id";
require-instance false;
}
description
"A type for an absolute reference to a termination point.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw:node-ref;
}
augment "/nw:networks/nw:network" {
description
"Add links to the network data model.";
list link {
key "link-id";
description
"A network link connects a local (source) node and
a remote (destination) node via a set of the respective
node's termination points. It is possible to have several
links between the same source and destination nodes.
Likewise, a link could potentially be re-homed between
termination points. Therefore, in order to ensure that we
would always know to distinguish between links, every link
is identified by a dedicated link identifier. Note that a
link models a point-to-point link, not a multipoint link.";
leaf link-id {
type link-id;
description
"The identifier of a link in the topology.
A link is specific to a topology to which it belongs.";
}
container source {
description
"This container holds the logical source of a particular
link.";
leaf source-node {
type leafref {
path "../../../nw:node/nw:node-id";
require-instance false;
}
description
"Source node identifier. Must be in the same topology.";
}
leaf source-tp {
type leafref {
path "../../../nw:node[nw:node-id=current()/../"+
"source-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the source node
and terminates the link.";
}
}
augment "/nw:networks/nw:network" {
description
"Add links to the network data model.";
list link {
key "link-id";
description
"A network link connects a local (source) node and
a remote (destination) node via a set of the respective
node's termination points. It is possible to have several
links between the same source and destination nodes.
Likewise, a link could potentially be re-homed between
termination points. Therefore, in order to ensure that we
would always know to distinguish between links, every link
is identified by a dedicated link identifier. Note that a
link models a point-to-point link, not a multipoint link.";
leaf link-id {
type link-id;
description
"The identifier of a link in the topology.
A link is specific to a topology to which it belongs.";
}
container source {
description
"This container holds the logical source of a particular
link.";
leaf source-node {
type leafref {
path "../../../nw:node/nw:node-id";
require-instance false;
}
description
"Source node identifier. Must be in the same topology.";
}
leaf source-tp {
type leafref {
path "../../../nw:node[nw:node-id=current()/../"+
"source-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the source node
and terminates the link.";
}
}
container destination {
description
"This container holds the logical destination of a
particular link.";
leaf dest-node {
type leafref {
path "../../../nw:node/nw:node-id";
require-instance false;
}
description
"Destination node identifier. Must be in the same
network.";
}
leaf dest-tp {
type leafref {
path "../../../nw:node[nw:node-id=current()/../"+
"dest-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the
destination node and terminates the link.";
}
}
list supporting-link {
key "network-ref link-ref";
description
"Identifies the link or links on which this link depends.";
leaf network-ref {
type leafref {
path "../../../nw:supporting-network/nw:network-ref";
require-instance false;
}
description
"This leaf identifies in which underlay topology
the supporting link is present.";
}
container destination {
description
"This container holds the logical destination of a
particular link.";
leaf dest-node {
type leafref {
path "../../../nw:node/nw:node-id";
require-instance false;
}
description
"Destination node identifier. Must be in the same
network.";
}
leaf dest-tp {
type leafref {
path "../../../nw:node[nw:node-id=current()/../"+
"dest-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the
destination node and terminates the link.";
}
}
list supporting-link {
key "network-ref link-ref";
description
"Identifies the link or links on which this link depends.";
leaf network-ref {
type leafref {
path "../../../nw:supporting-network/nw:network-ref";
require-instance false;
}
description
"This leaf identifies in which underlay topology
the supporting link is present.";
}
leaf link-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/"+
"../network-ref]/link/link-id";
require-instance false;
}
description
"This leaf identifies a link that is a part
of this link's underlay. Reference loops in which
a link identifies itself as its underlay, either
directly or transitively, are not allowed.";
}
}
}
}
augment "/nw:networks/nw:network/nw:node" {
description
"Augments termination points that terminate links.
Termination points can ultimately be mapped to interfaces.";
list termination-point {
key "tp-id";
description
"A termination point can terminate a link.
Depending on the type of topology, a termination point
could, for example, refer to a port or an interface.";
leaf tp-id {
type tp-id;
description
"Termination point identifier.";
}
list supporting-termination-point {
key "network-ref node-ref tp-ref";
description
"This list identifies any termination points on which a
given termination point depends or onto which it maps.
Those termination points will themselves be contained
in a supporting node. This dependency information can be
inferred from the dependencies between links. Therefore,
this item is not separately configurable. Hence, no
corresponding constraint needs to be articulated.
The corresponding information is simply provided by the
implementing system.";
leaf link-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/"+
"../network-ref]/link/link-id";
require-instance false;
}
description
"This leaf identifies a link that is a part
of this link's underlay. Reference loops in which
a link identifies itself as its underlay, either
directly or transitively, are not allowed.";
}
}
}
}
augment "/nw:networks/nw:network/nw:node" {
description
"Augments termination points that terminate links.
Termination points can ultimately be mapped to interfaces.";
list termination-point {
key "tp-id";
description
"A termination point can terminate a link.
Depending on the type of topology, a termination point
could, for example, refer to a port or an interface.";
leaf tp-id {
type tp-id;
description
"Termination point identifier.";
}
list supporting-termination-point {
key "network-ref node-ref tp-ref";
description
"This list identifies any termination points on which a
given termination point depends or onto which it maps.
Those termination points will themselves be contained
in a supporting node. This dependency information can be
inferred from the dependencies between links. Therefore,
this item is not separately configurable. Hence, no
corresponding constraint needs to be articulated.
The corresponding information is simply provided by the
implementing system.";
leaf network-ref {
type leafref {
path "../../../nw:supporting-node/nw:network-ref";
require-instance false;
}
description
"This leaf identifies in which topology the
supporting termination point is present.";
}
leaf node-ref {
type leafref {
path "../../../nw:supporting-node/nw:node-ref";
require-instance false;
}
description
"This leaf identifies in which node the supporting
termination point is present.";
}
leaf tp-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/"+
"../network-ref]/nw:node[nw:node-id=current()/../"+
"node-ref]/termination-point/tp-id";
require-instance false;
}
description
"Reference to the underlay node (the underlay node must
be in a different topology).";
}
}
}
}
}
leaf network-ref {
type leafref {
path "../../../nw:supporting-node/nw:network-ref";
require-instance false;
}
description
"This leaf identifies in which topology the
supporting termination point is present.";
}
leaf node-ref {
type leafref {
path "../../../nw:supporting-node/nw:node-ref";
require-instance false;
}
description
"This leaf identifies in which node the supporting
termination point is present.";
}
leaf tp-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/"+
"../network-ref]/nw:node[nw:node-id=current()/../"+
"node-ref]/termination-point/tp-id";
require-instance false;
}
description
"Reference to the underlay node (the underlay node must
be in a different topology).";
}
}
}
}
}
<CODE ENDS>
<代码结束>
This document registers the following namespace URIs in the "IETF XML Registry" [RFC3688]:
本文档在“IETF XML注册表”[RFC3688]中注册以下命名空间URI：
URI: urn:ietf:params:xml:ns:yang:ietf-network Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf网络注册人联系人：IESG。XML：不适用；请求的URI是一个XML命名空间。
URI: urn:ietf:params:xml:ns:yang:ietf-network-topology Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf网络拓扑注册人联系人：IESG。XML：不适用；请求的URI是一个XML命名空间。
URI: urn:ietf:params:xml:ns:yang:ietf-network-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf网络状态注册人联系人：IESG。XML：不适用；请求的URI是一个XML命名空间。
URI: urn:ietf:params:xml:ns:yang:ietf-network-topology-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf网络拓扑状态注册人联系人：IESG。XML：不适用；请求的URI是一个XML命名空间。
This document registers the following YANG modules in the "YANG Module Names" registry [RFC6020]:
本文件在“YANG模块名称”注册表[RFC6020]中注册以下YANG模块：
Name: ietf-network
Namespace: urn:ietf:params:xml:ns:yang:ietf-network
Prefix: nw
Reference: RFC 8345
Name: ietf-network
Namespace: urn:ietf:params:xml:ns:yang:ietf-network
Prefix: nw
Reference: RFC 8345
Name: ietf-network-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology
Prefix: nt
Reference: RFC 8345
Name: ietf-network-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology
Prefix: nt
Reference: RFC 8345
Name: ietf-network-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state
Prefix: nw-s
Reference: RFC 8345
Name: ietf-network-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state
Prefix: nw-s
Reference: RFC 8345
Name: ietf-network-topology-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state
Prefix: nt-s
Reference: RFC 8345
Name: ietf-network-topology-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state
Prefix: nt-s
Reference: RFC 8345
The YANG modules specified in this document define 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 [RFC5246].
本文档中指定的模块为数据定义了一个模式，该模式旨在通过网络管理协议（如NETCONF[RFC6241]或restcconf[RFC8040]）进行访问。最低的NETCONF层是安全传输层，实现安全传输的强制要求是安全Shell（SSH）[RFC6242]。最低的RESTCONF层是HTTPS，实现安全传输的强制层是TLS[RFC5246]。
The NETCONF access control model [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.
NETCONF访问控制模型[RFC8341]提供了将特定NETCONF或RESTCONF用户的访问限制为所有可用NETCONF或RESTCONF协议操作和内容的预配置子集的方法。
The network topology and inventory created by these modules reveal information about the structure of networks that could be very helpful to an attacker. As a privacy consideration, although there is no personally identifiable information defined in these modules, it is possible that some node identifiers may be associated with devices that are in turn associated with specific users.
这些模块创建的网络拓扑和资源清册揭示了有关网络结构的信息，这些信息可能对攻击者非常有用。出于隐私考虑，尽管在这些模块中没有定义个人可识别信息，但一些节点标识符可能与设备相关联，而这些设备又与特定用户相关联。
The YANG modules define information that can be configurable in certain instances -- for example, in the case of overlay topologies that can be created by client applications. In such cases, a malicious client could introduce topologies that are undesired. Specifically, a malicious client could attempt to remove or add a node, a link, or a termination point by creating or deleting corresponding elements in node, link, or termination point lists, respectively. In the case of a topology that is learned, the server will automatically prohibit such misconfiguration attempts. In the case of a topology that is configured, i.e., whose origin is "intended", the undesired configuration could become effective and be reflected in the operational state datastore, leading to disruption of services provided via this topology. For example, the topology could be "cut" or could be configured in a suboptimal way, leading to increased consumption of resources in the underlay network due to the routing and bandwidth utilization inefficiencies that would result. Likewise, it could lead to degradation of service levels as well as possible disruption of service. For those reasons, it is important that the NETCONF access control model be vigorously applied to prevent topology misconfiguration by unauthorized clients.
这些模块定义了在某些情况下可以配置的信息——例如，在可以由客户端应用程序创建的覆盖拓扑的情况下。在这种情况下，恶意客户端可能引入不需要的拓扑。具体而言，恶意客户端可能会试图通过分别在节点、链接或终止点列表中创建或删除相应元素来删除或添加节点、链接或终止点。对于已学习的拓扑，服务器将自动禁止此类错误配置尝试。在配置了拓扑的情况下，即其来源是“预期的”，不期望的配置可能会生效并反映在操作状态数据存储中，从而导致通过该拓扑提供的服务中断。例如，拓扑可能被“切割”或以次优的方式配置，由于可能导致的路由和带宽利用效率低下，导致底层网络中的资源消耗增加。同样，它可能会导致服务级别降低，并可能导致服务中断。出于这些原因，必须大力应用NETCONF访问控制模型，以防止未经授权的客户端错误配置拓扑。
There are a number of data nodes defined in these YANG modules 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)
这些模块中定义了许多数据节点，这些节点是可写/可创建/可删除的（即config true，这是默认值）。在某些网络环境中，这些数据节点可能被视为敏感或易受攻击。写入操作（例如，编辑配置）
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:
对这些数据节点不进行适当的保护可能会对网络运行产生负面影响。这些是子树和数据节点及其敏感性/漏洞：
In the "ietf-network" module:
在“ietf网络”模块中：
o network: A malicious client could attempt to remove or add a network in an effort to remove an overlay topology or to create an unauthorized overlay.
o 网络：恶意客户端可能试图删除或添加网络，以删除覆盖拓扑或创建未经授权的覆盖。
o supporting network: A malicious client could attempt to disrupt the logical structure of the model, resulting in a lack of overall data integrity and making it more difficult to, for example, troubleshoot problems rooted in the layering of network topologies.
o 支持网络：恶意客户端可能试图破坏模型的逻辑结构，导致缺乏整体数据完整性，并使解决网络拓扑分层问题变得更加困难。
o node: A malicious client could attempt to remove or add a node from the network -- for example, in order to sabotage the topology of a network overlay.
o 节点：恶意客户端可能试图从网络中删除或添加节点——例如，为了破坏网络覆盖的拓扑结构。
o supporting node: A malicious client could attempt to change the supporting node in order to sabotage the layering of an overlay.
o 支持节点：恶意客户端可能试图更改支持节点以破坏覆盖层的分层。
In the "ietf-network-topology" module:
在“ietf网络拓扑”模块中：
o link: A malicious client could attempt to remove a link from a topology, add a new link, manipulate the way the link is layered over supporting links, or modify the source or destination of the link. In each case, the structure of the topology would be sabotaged, and this scenario could, for example, result in an overlay topology that is less than optimal.
o 链接：恶意客户端可能试图从拓扑中删除链接、添加新链接、操纵链接在支持链接上的分层方式，或修改链接的源或目标。在每种情况下，拓扑结构都会受到破坏，例如，这种情况可能会导致不太理想的覆盖拓扑。
o termination point: A malicious client could attempt to remove termination points from a node, add "phantom" termination points to a node, or change the layering dependencies of termination points, again in an effort to sabotage the integrity of a topology and potentially disrupt orderly operations of an overlay.
o 终止点：恶意客户端可能试图从节点删除终止点，向节点添加“幻影”终止点，或更改终止点的分层依赖关系，再次破坏拓扑的完整性，并可能破坏覆盖的有序操作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<https://www.rfc-editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[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>.
[RFC6020]Bjorklund，M.，Ed.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 6020，DOI 10.17487/RFC6020，2010年10月<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>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<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>.
[RFC6242]Wasserman，M.“在安全外壳上使用NETCONF协议（SSH）”，RFC 6242，DOI 10.17487/RFC6242，2011年6月<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>.
[RFC6991]Schoenwaeld，J.，Ed.，“常见杨数据类型”，RFC 6991，DOI 10.17487/RFC69911913年7月<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>.
[RFC7950]Bjorklund，M.，Ed.“YANG 1.1数据建模语言”，RFC 7950，DOI 10.17487/RFC7950，2016年8月<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>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC8341]Bierman，A.和M.Bjorklund，“网络配置访问控制模型”，STD 91，RFC 8341，DOI 10.17487/RFC8341，2018年3月<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>.
[RFC8342]Bjorklund，M.，Schoenwaeld，J.，Shafer，P.，Watsen，K.，和R.Wilton，“网络管理数据存储体系结构（NMDA）”，RFC 8342，DOI 10.17487/RFC8342，2018年3月<https://www.rfc-editor.org/info/rfc8342>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC1195]Callon，R.“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 1195，DOI 10.17487/RFC1195，1990年12月<https://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，DOI 10.17487/RFC2328，1998年4月<https://www.rfc-editor.org/info/rfc2328>.
[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：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC3444]Pras，A.和J.Schoenwaeld，“关于信息模型和数据模型之间的差异”，RFC 3444，DOI 10.17487/RFC3444，2003年1月<https://www.rfc-editor.org/info/rfc3444>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.
[RFC7951]Lhotka，L.，“用YANG建模的数据的JSON编码”，RFC 7951，DOI 10.17487/RFC7951，2016年8月<https://www.rfc-editor.org/info/rfc7951>.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-editor.org/info/rfc7952>.
[RFC7952]Lhotka，L.，“与YANG一起定义和使用元数据”，RFC 7952，DOI 10.17487/RFC7952，2016年8月<https://www.rfc-editor.org/info/rfc7952>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", RFC 8022, DOI 10.17487/RFC8022, November 2016, <https://www.rfc-editor.org/info/rfc8022>.
[RFC8022]Lhotka，L.和A.Lindem，“路由管理的YANG数据模型”，RFC 8022，DOI 10.17487/RFC8022，2016年11月<https://www.rfc-editor.org/info/rfc8022>.
[RFC8242] Haas, J. and S. Hares, "Interface to the Routing System (I2RS) Ephemeral State Requirements", RFC 8242, DOI 10.17487/RFC8242, September 2017, <https://www.rfc-editor.org/info/rfc8242>.
[RFC8242]Haas，J.和S.Hares，“路由系统接口（I2RS）临时状态要求”，RFC 8242，DOI 10.17487/RFC8242，2017年9月<https://www.rfc-editor.org/info/rfc8242>.
[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>.
[RFC8340]Bjorklund，M.和L.Berger，编辑，“杨树图”，BCP 215，RFC 8340，DOI 10.17487/RFC8340，2018年3月<https://www.rfc-editor.org/info/rfc8340>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343]Bjorklund，M.，“用于接口管理的YANG数据模型”，RFC 8343，DOI 10.17487/RFC8343，2018年3月<https://www.rfc-editor.org/info/rfc8343>.
[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, March 2018, <https://www.rfc-editor.org/info/rfc8346>.
[RFC8346]Clemm，A.，Medved，J.，Varga，R.，Liu，X.，Ananthakrishnan，H.，和N.Bahadur，“第3层拓扑的杨数据模型”，RFC 8346，DOI 10.17487/RFC8346，2018年3月<https://www.rfc-editor.org/info/rfc8346>.
[USECASE-REQS] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", Work in Progress, draft-ietf-i2rs-usecase-reqs-summary-03, November 2016.
[USECASE-REQS]Hares，S.和M.Chen，“I2RS用例需求概要”，正在进行的工作，草稿-ietf-I2RS-USECASE-REQS-Summary-032016年11月。
[YANG-Push] Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore Subscription", Work in Progress, draft-ietf-netconf-yang-push-15, February 2018.
[YANG Push]Clemm，A.，Voit，E.，Gonzalez Prieto，A.，Tripathy，A.，Nilsen Nygaard，E.，Bierman，A.，和B.Lengyel，“YANG数据存储订阅”，正在进行的工作，草稿-ietf-netconf-YANG-Push-15，2018年2月。
In its simplest form, topology is learned by a network element (e.g., a router) through its participation in peering protocols (IS-IS, BGP, etc.). This learned topology can then be exported (e.g., to a Network Management System) for external utilization. Typically, any network element in a domain can be queried for its topology and be expected to return the same result.
在其最简单的形式中，网络元件（例如路由器）通过参与对等协议（is-is、BGP等）来学习拓扑。然后，可以将该学习到的拓扑导出（例如，到网络管理系统）以供外部使用。通常，可以查询域中的任何网元的拓扑，并期望返回相同的结果。
In a slightly more complex form, the network element may be a controller. It could be a network element with satellite or subtended devices hanging off of it, or it could be a controller in the more classical sense -- that is, a special device designated to orchestrate the activities of a number of other devices (e.g., an Optical Controller). In this case, the controller device is logically a singleton and must be queried distinctly.
在稍微复杂的形式中，网络元件可以是控制器。它可以是悬挂着卫星或附属设备的网元，也可以是更经典意义上的控制器——也就是说，指定用于协调许多其他设备（例如，光学控制器）活动的特殊设备。在这种情况下，控制器设备在逻辑上是单例的，必须明确地进行查询。
It is worth noting that controllers can be built on top of other controllers to establish a topology incorporating all of the domains within an entire network.
值得注意的是，可以在其他控制器的基础上构建控制器，以建立包含整个网络中所有域的拓扑。
In all of the cases above, the topology learned by the network element is considered to be operational state data. That is, the data is accumulated purely by the network element's interactions with other systems and is subject to change dynamically without input or consent.
在上述所有情况下，网元学习到的拓扑被视为操作状态数据。也就是说，数据纯粹是通过网元与其他系统的交互累积的，并且可以在没有输入或同意的情况下动态更改。
Consider a scenario where an Optical Controller presents its topology, in abstract TE terms, to a client packet controller. This customized topology (which gets merged into the client's native topology) contains sufficient information for the path-computing client to select paths across the optical domain according to its policies. If the client determines (at any given point in time) that this imported topology does not cater exactly to its requirements, it may decide to request modifications to the topology. Such customization requests may include the addition or deletion of topological elements or the modification of attributes associated with existing topological elements. From the perspective of the Optical Controller, these requests translate into configuration changes to the exported abstract topology.
考虑一种场景，其中光学控制器以抽象的术语将其拓扑呈现给客户端分组控制器。此自定义拓扑（合并到客户端的本机拓扑中）包含足够的信息，路径计算客户端可以根据其策略选择光域中的路径。如果客户确定（在任何给定时间点）此导入的拓扑不完全符合其要求，则可能会决定请求对拓扑进行修改。此类定制请求可能包括添加或删除拓扑元素或修改与现有拓扑元素相关的属性。从光控制器的角度来看，这些请求转化为对导出的抽象拓扑的配置更改。
In certain scenarios, the topology learned by a controller needs to be augmented with additional attributes before running a computation algorithm on it. Consider the case where a path-computation application on the controller needs to take the geographic coordinates of the nodes into account while computing paths on the learned topology. If the learned topology does not contain these coordinates, then these additional attributes must be configured on the corresponding topological elements.
在某些情况下，在控制器上运行计算算法之前，需要使用附加属性对其学习的拓扑进行扩充。考虑在控制器上的路径计算应用需要考虑节点的地理坐标的同时计算学习拓扑上的路径的情况。如果学习的拓扑不包含这些坐标，则必须在相应的拓扑元素上配置这些附加属性。
In this scenario, an SDN Controller (for example, Open Daylight) maintains a view of the topology of the network that it controls based on information that it discovers from the network. In addition, it provides an application in which it configures and maintains an overlay topology.
在此场景中，SDN控制器（例如，开放日光）根据从网络中发现的信息维护其控制的网络拓扑视图。此外，它还提供了一个应用程序，用于配置和维护覆盖拓扑。
The SDN Controller thus maintains two roles:
因此，SDN控制器维护两个角色：
o It is a client to the network.
o 它是网络的客户端。
o It is a server to its own northbound applications and clients, e.g., an Operations Support System (OSS).
o 它是一个服务器，用于连接自己的北行应用程序和客户端，例如操作支持系统（OSS）。
In other words, one system's client (or controller, in this case) may be another system's server (or managed system).
换句话说，一个系统的客户端（或控制器，在本例中）可能是另一个系统的服务器（或托管系统）。
In this scenario, the SDN Controller maintains a consolidated data model of multiple layers of topology. This includes the lower layers of the network topology, built from information that is discovered from the network. It also includes upper layers of topology overlay, configurable by the controller's client, i.e., the OSS. To the OSS, the lower topology layers constitute "read-only" information. The upper topology layers need to be read-writable.
在此场景中，SDN控制器维护多层拓扑的整合数据模型。这包括网络拓扑的较低层，它是根据从网络中发现的信息构建的。它还包括拓扑覆盖的上层，可由控制器的客户端（即OSS）配置。对于OSS，较低的拓扑层构成“只读”信息。上层拓扑层需要可读写。
Appendix B. Companion YANG Data Models for Implementations Not Compliant with NMDA
附录B.不符合NMDA的实施数据模型
The YANG modules defined in this document are designed to be used in conjunction with implementations that support the Network Management Datastore Architecture (NMDA) as defined in [RFC8342]. In order to allow implementations to use the data model even in cases when NMDA is not supported, the following two companion modules -- "ietf-network-state" and "ietf-network-topology-state" -- are defined; they represent the operational state of networks and network topologies, respectively. These modules mirror the "ietf-network"
本文档中定义的模块设计用于与支持[RFC8342]中定义的网络管理数据存储体系结构（NMDA）的实现结合使用。为了允许实现在不支持NMDA的情况下使用数据模型，定义了以下两个配套模块——“ietf网络状态”和“ietf网络拓扑状态”；它们分别表示网络和网络拓扑的运行状态。这些模块反映了“ietf网络”
and "ietf-network-topology" modules (defined in Sections 6.1 and 6.2 of this document); however, in the case of these modules, all data nodes are non-configurable. They represent state that comes into being by either (1) learning topology information from the network or (2) applying configuration from the mirrored modules.
和“ietf网络拓扑”模块（定义见本文件第6.1节和第6.2节）；但是，对于这些模块，所有数据节点都是不可配置的。它们表示通过（1）从网络学习拓扑信息或（2）从镜像模块应用配置而形成的状态。
The "ietf-network-state" and "ietf-network-topology-state" companion modules are redundant and SHOULD NOT be supported by implementations that support NMDA; therefore, we define these modules in Appendices B.1 and B.2 (below) instead of the main body of this document.
“ietf网络状态”和“ietf网络拓扑状态”伴随模块是冗余的，支持NMDA的实现不应支持这些模块；因此，我们在附录B.1和B.2（下文）中定义了这些模块，而不是本文件的主体部分。
As the structure of both modules mirrors that of their underlying modules, the YANG tree is not depicted separately.
由于两个模块的结构都反映了其底层模块的结构，因此不会单独描述杨树。
<CODE BEGINS> file "ietf-network-state@2018-02-26.yang"
<CODE BEGINS> file "ietf-network-state@2018-02-26.yang"
module ietf-network-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";
prefix nw-s;
module ietf-network-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";
prefix nw-s;
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
organization "IETF I2RS (Interface to the Routing System) Working Group";
组织“IETF I2RS（路由系统接口）工作组”；
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
description "This module defines a common base data model for a collection of nodes in a network. Node definitions are further used in network topologies and inventories. It represents information that either (1) is learned and automatically populated or (2) results from applying network information that has been configured per the 'ietf-network' data model, mirroring the corresponding data nodes in this data model.
description“此模块为网络中的节点集合定义公共基础数据模型。节点定义进一步用于网络拓扑和资源清册。它表示（1）学习并自动填充的信息，或（2）表示应用已根据“ietf网络”数据模型配置的网络信息，镜像此数据模型中的相应数据节点的结果。
The data model mirrors 'ietf-network' but contains only read-only state data. The data model is not needed when the underlying implementation infrastructure supports the Network Management Datastore Architecture (NMDA).
数据模型镜像“ietf网络”，但仅包含只读状态数据。当底层实施基础设施支持网络管理数据存储体系结构（NMDA）时，不需要数据模型。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2018 IETF信托基金和被确定为代码作者的人员。版权所有。
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 Simplified 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).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8345;
see the RFC itself for full legal notices.";
This version of this YANG module is part of RFC 8345;
see the RFC itself for full legal notices.";
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
grouping network-ref {
description
"Contains the information necessary to reference a network --
for example, an underlay network.";
leaf network-ref {
type leafref {
path "/nw-s:networks/nw-s:network/nw-s:network-id";
require-instance false;
}
description
"Used to reference a network -- for example, an underlay
network.";
}
}
grouping network-ref {
description
"Contains the information necessary to reference a network --
for example, an underlay network.";
leaf network-ref {
type leafref {
path "/nw-s:networks/nw-s:network/nw-s:network-id";
require-instance false;
}
description
"Used to reference a network -- for example, an underlay
network.";
}
}
grouping node-ref {
description
"Contains the information necessary to reference a node.";
leaf node-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
"/../network-ref]/nw-s:node/nw-s:node-id";
require-instance false;
}
description
"Used to reference a node.
Nodes are identified relative to the network that
contains them.";
}
uses network-ref;
}
grouping node-ref {
description
"Contains the information necessary to reference a node.";
leaf node-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
"/../network-ref]/nw-s:node/nw-s:node-id";
require-instance false;
}
description
"Used to reference a node.
Nodes are identified relative to the network that
contains them.";
}
uses network-ref;
}
container networks {
config false;
description
"Serves as a top-level container for a list of networks.";
list network {
key "network-id";
description
"Describes a network.
A network typically contains an inventory of nodes,
topological information (augmented through the
network-topology data model), and layering information.";
container network-types {
description
"Serves as an augmentation target.
The network type is indicated through corresponding
presence containers augmented into this container.";
}
leaf network-id {
type nw:network-id;
description
"Identifies a network.";
}
list supporting-network {
key "network-ref";
description
"An underlay network, used to represent layered network
topologies.";
leaf network-ref {
type leafref {
path "/nw-s:networks/nw-s:network/nw-s:network-id";
require-instance false;
}
description
"References the underlay network.";
}
}
container networks {
config false;
description
"Serves as a top-level container for a list of networks.";
list network {
key "network-id";
description
"Describes a network.
A network typically contains an inventory of nodes,
topological information (augmented through the
network-topology data model), and layering information.";
container network-types {
description
"Serves as an augmentation target.
The network type is indicated through corresponding
presence containers augmented into this container.";
}
leaf network-id {
type nw:network-id;
description
"Identifies a network.";
}
list supporting-network {
key "network-ref";
description
"An underlay network, used to represent layered network
topologies.";
leaf network-ref {
type leafref {
path "/nw-s:networks/nw-s:network/nw-s:network-id";
require-instance false;
}
description
"References the underlay network.";
}
}
list node {
key "node-id";
description
"The inventory of nodes of this network.";
leaf node-id {
type nw:node-id;
description
"Uniquely identifies a node within the containing
network.";
}
list supporting-node {
key "network-ref node-ref";
description
"Represents another node that is in an underlay network
and that supports this node. Used to represent layering
structure.";
leaf network-ref {
type leafref {
path "../../../nw-s:supporting-network/nw-s:network-ref";
require-instance false;
}
description
"References the underlay network of which the
underlay node is a part.";
}
leaf node-ref {
type leafref {
path "/nw-s:networks/nw-s:network/nw-s:node/nw-s:node-id";
require-instance false;
}
description
"References the underlay node itself.";
}
}
}
}
}
}
list node {
key "node-id";
description
"The inventory of nodes of this network.";
leaf node-id {
type nw:node-id;
description
"Uniquely identifies a node within the containing
network.";
}
list supporting-node {
key "network-ref node-ref";
description
"Represents another node that is in an underlay network
and that supports this node. Used to represent layering
structure.";
leaf network-ref {
type leafref {
path "../../../nw-s:supporting-network/nw-s:network-ref";
require-instance false;
}
description
"References the underlay network of which the
underlay node is a part.";
}
leaf node-ref {
type leafref {
path "/nw-s:networks/nw-s:network/nw-s:node/nw-s:node-id";
require-instance false;
}
description
"References the underlay node itself.";
}
}
}
}
}
}
<CODE ENDS>
<代码结束>
<CODE BEGINS> file "ietf-network-topology-state@2018-02-26.yang"
<CODE BEGINS> file "ietf-network-topology-state@2018-02-26.yang"
module ietf-network-topology-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";
prefix nt-s;
module ietf-network-topology-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";
prefix nt-s;
import ietf-network-state {
prefix nw-s;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-state {
prefix nw-s;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
organization "IETF I2RS (Interface to the Routing System) Working Group";
组织“IETF I2RS（路由系统接口）工作组”；
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
description "This module defines a common base data model for network topology state, representing topology that either (1) is learned or (2) results from applying topology that has been configured per the 'ietf-network-topology' data model, mirroring the corresponding data nodes in this data model. It augments the base network state data model with links to connect nodes, as well as termination points to terminate links on nodes.
description“此模块为网络拓扑状态定义公共基础数据模型，表示（1）已学习的拓扑或（2）已学习的拓扑应用已根据“ietf网络拓扑”数据模型配置的拓扑，镜像此数据模型中的相应数据节点后产生的结果。它使用连接节点的链接以及终止节点上链接的终止点来扩展基本网络状态数据模型。
The data model mirrors 'ietf-network-topology' but contains only read-only state data. The data model is not needed when the underlying implementation infrastructure supports the Network Management Datastore Architecture (NMDA).
数据模型镜像“ietf网络拓扑”，但仅包含只读状态数据。当底层实施基础设施支持网络管理数据存储体系结构（NMDA）时，不需要数据模型。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2018 IETF信托基金和被确定为代码作者的人员。版权所有。
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 Simplified 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).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8345;
see the RFC itself for full legal notices.";
This version of this YANG module is part of RFC 8345;
see the RFC itself for full legal notices.";
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
grouping link-ref {
description
"References a link in a specific network. Although this
grouping is not used in this module, it is defined here for
the convenience of augmenting modules.";
leaf link-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
"/../network-ref]/nt-s:link/nt-s:link-id";
require-instance false;
}
description
"A type for an absolute reference to a link instance.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw-s:network-ref;
}
grouping link-ref {
description
"References a link in a specific network. Although this
grouping is not used in this module, it is defined here for
the convenience of augmenting modules.";
leaf link-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
"/../network-ref]/nt-s:link/nt-s:link-id";
require-instance false;
}
description
"A type for an absolute reference to a link instance.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw-s:network-ref;
}
grouping tp-ref {
description
"References a termination point in a specific node. Although
this grouping is not used in this module, it is defined here
for the convenience of augmenting modules.";
leaf tp-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
"/../network-ref]/nw-s:node[nw-s:node-id=current()/../"+
"node-ref]/nt-s:termination-point/nt-s:tp-id";
require-instance false;
}
description
"A type for an absolute reference to a termination point.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw-s:node-ref;
}
grouping tp-ref {
description
"References a termination point in a specific node. Although
this grouping is not used in this module, it is defined here
for the convenience of augmenting modules.";
leaf tp-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
"/../network-ref]/nw-s:node[nw-s:node-id=current()/../"+
"node-ref]/nt-s:termination-point/nt-s:tp-id";
require-instance false;
}
description
"A type for an absolute reference to a termination point.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw-s:node-ref;
}
augment "/nw-s:networks/nw-s:network" {
description
"Add links to the network data model.";
list link {
key "link-id";
description
"A network link connects a local (source) node and
a remote (destination) node via a set of the respective
node's termination points. It is possible to have several
augment "/nw-s:networks/nw-s:network" {
description
"Add links to the network data model.";
list link {
key "link-id";
description
"A network link connects a local (source) node and
a remote (destination) node via a set of the respective
node's termination points. It is possible to have several
links between the same source and destination nodes.
Likewise, a link could potentially be re-homed between
termination points. Therefore, in order to ensure that we
would always know to distinguish between links, every link
is identified by a dedicated link identifier. Note that a
link models a point-to-point link, not a multipoint link.";
container source {
description
"This container holds the logical source of a particular
link.";
leaf source-node {
type leafref {
path "../../../nw-s:node/nw-s:node-id";
require-instance false;
}
description
"Source node identifier. Must be in the same topology.";
}
leaf source-tp {
type leafref {
path "../../../nw-s:node[nw-s:node-id=current()/../"+
"source-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the source node
and terminates the link.";
}
}
container destination {
description
"This container holds the logical destination of a
particular link.";
leaf dest-node {
type leafref {
path "../../../nw-s:node/nw-s:node-id";
require-instance false;
}
description
"Destination node identifier. Must be in the same
network.";
}
links between the same source and destination nodes.
Likewise, a link could potentially be re-homed between
termination points. Therefore, in order to ensure that we
would always know to distinguish between links, every link
is identified by a dedicated link identifier. Note that a
link models a point-to-point link, not a multipoint link.";
container source {
description
"This container holds the logical source of a particular
link.";
leaf source-node {
type leafref {
path "../../../nw-s:node/nw-s:node-id";
require-instance false;
}
description
"Source node identifier. Must be in the same topology.";
}
leaf source-tp {
type leafref {
path "../../../nw-s:node[nw-s:node-id=current()/../"+
"source-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the source node
and terminates the link.";
}
}
container destination {
description
"This container holds the logical destination of a
particular link.";
leaf dest-node {
type leafref {
path "../../../nw-s:node/nw-s:node-id";
require-instance false;
}
description
"Destination node identifier. Must be in the same
network.";
}
leaf dest-tp {
type leafref {
path "../../../nw-s:node[nw-s:node-id=current()/../"+
"dest-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the
destination node and terminates the link.";
}
}
leaf link-id {
type nt:link-id;
description
"The identifier of a link in the topology.
A link is specific to a topology to which it belongs.";
}
list supporting-link {
key "network-ref link-ref";
description
"Identifies the link or links on which this link depends.";
leaf network-ref {
type leafref {
path "../../../nw-s:supporting-network/nw-s:network-ref";
require-instance false;
}
description
"This leaf identifies in which underlay topology
the supporting link is present.";
}
leaf link-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id="+
"current()/../network-ref]/link/link-id";
require-instance false;
}
description
"This leaf identifies a link that is a part
of this link's underlay. Reference loops in which
a link identifies itself as its underlay, either
directly or transitively, are not allowed.";
}
}
}
}
leaf dest-tp {
type leafref {
path "../../../nw-s:node[nw-s:node-id=current()/../"+
"dest-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the
destination node and terminates the link.";
}
}
leaf link-id {
type nt:link-id;
description
"The identifier of a link in the topology.
A link is specific to a topology to which it belongs.";
}
list supporting-link {
key "network-ref link-ref";
description
"Identifies the link or links on which this link depends.";
leaf network-ref {
type leafref {
path "../../../nw-s:supporting-network/nw-s:network-ref";
require-instance false;
}
description
"This leaf identifies in which underlay topology
the supporting link is present.";
}
leaf link-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id="+
"current()/../network-ref]/link/link-id";
require-instance false;
}
description
"This leaf identifies a link that is a part
of this link's underlay. Reference loops in which
a link identifies itself as its underlay, either
directly or transitively, are not allowed.";
}
}
}
}
augment "/nw-s:networks/nw-s:network/nw-s:node" {
description
"Augments termination points that terminate links.
Termination points can ultimately be mapped to interfaces.";
list termination-point {
key "tp-id";
description
"A termination point can terminate a link.
Depending on the type of topology, a termination point
could, for example, refer to a port or an interface.";
leaf tp-id {
type nt:tp-id;
description
"Termination point identifier.";
}
list supporting-termination-point {
key "network-ref node-ref tp-ref";
description
"This list identifies any termination points on which a
given termination point depends or onto which it maps.
Those termination points will themselves be contained
in a supporting node. This dependency information can be
inferred from the dependencies between links. Therefore,
this item is not separately configurable. Hence, no
corresponding constraint needs to be articulated.
The corresponding information is simply provided by the
implementing system.";
leaf network-ref {
type leafref {
path "../../../nw-s:supporting-node/nw-s:network-ref";
require-instance false;
}
description
"This leaf identifies in which topology the
supporting termination point is present.";
}
leaf node-ref {
type leafref {
path "../../../nw-s:supporting-node/nw-s:node-ref";
require-instance false;
}
description
"This leaf identifies in which node the supporting
termination point is present.";
}
augment "/nw-s:networks/nw-s:network/nw-s:node" {
description
"Augments termination points that terminate links.
Termination points can ultimately be mapped to interfaces.";
list termination-point {
key "tp-id";
description
"A termination point can terminate a link.
Depending on the type of topology, a termination point
could, for example, refer to a port or an interface.";
leaf tp-id {
type nt:tp-id;
description
"Termination point identifier.";
}
list supporting-termination-point {
key "network-ref node-ref tp-ref";
description
"This list identifies any termination points on which a
given termination point depends or onto which it maps.
Those termination points will themselves be contained
in a supporting node. This dependency information can be
inferred from the dependencies between links. Therefore,
this item is not separately configurable. Hence, no
corresponding constraint needs to be articulated.
The corresponding information is simply provided by the
implementing system.";
leaf network-ref {
type leafref {
path "../../../nw-s:supporting-node/nw-s:network-ref";
require-instance false;
}
description
"This leaf identifies in which topology the
supporting termination point is present.";
}
leaf node-ref {
type leafref {
path "../../../nw-s:supporting-node/nw-s:node-ref";
require-instance false;
}
description
"This leaf identifies in which node the supporting
termination point is present.";
}
leaf tp-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id="+
"current()/../network-ref]/nw-s:node[nw-s:node-id="+
"current()/../node-ref]/termination-point/tp-id";
require-instance false;
}
description
"Reference to the underlay node (the underlay node must
be in a different topology).";
}
}
}
}
}
leaf tp-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id="+
"current()/../network-ref]/nw-s:node[nw-s:node-id="+
"current()/../node-ref]/termination-point/tp-id";
require-instance false;
}
description
"Reference to the underlay node (the underlay node must
be in a different topology).";
}
}
}
}
}
<CODE ENDS>
<代码结束>
This section contains an example of an instance data tree in JSON encoding [RFC7951]. The example instantiates "ietf-network-topology" (and "ietf-network", which "ietf-network-topology" augments) for the topology depicted in Figure 7. There are three nodes: D1, D2, and D3. D1 has three termination points (1-0-1, 1-2-1, and 1-3-1). D2 has three termination points as well (2-1-1, 2-0-1, and 2-3-1). D3 has two termination points (3-1-1 and 3-2-1). In addition, there are six links, two between each pair of nodes with one going in each direction.
本节包含JSON编码[RFC7951]中的实例数据树示例。该示例为图7所示的拓扑实例化了“ietf网络拓扑”（以及“ietf网络拓扑”扩充的“ietf网络）。有三个节点：D1、D2和D3。D1有三个端点（1-0-1、1-2-1和1-3-1）。D2也有三个端点（2-1-1、2-0-1和2-3-1）。D3有两个端点（3-1-1和3-2-1）。此外，有六条链路，每对节点之间有两条链路，每个方向有一条链路。
+------------+ +------------+
| D1 | | D2 |
/-\ /-\ /-\ /-\
| | 1-0-1 | |---------------->| | 2-1-1 | |
| | 1-2-1 | |<----------------| | 2-0-1 | |
\-/ 1-3-1 \-/ \-/ 2-3-1 \-/
| /----\ | | /----\ |
+---| |---+ +---| |---+
\----/ \----/
A | A |
| | | |
| | | |
| | +------------+ | |
| | | D3 | | |
| | /-\ /-\ | |
| +----->| | 3-1-1 | |-------+ |
+---------| | 3-2-1 | |<---------+
\-/ \-/
| |
+------------+
+------------+ +------------+
| D1 | | D2 |
/-\ /-\ /-\ /-\
| | 1-0-1 | |---------------->| | 2-1-1 | |
| | 1-2-1 | |<----------------| | 2-0-1 | |
\-/ 1-3-1 \-/ \-/ 2-3-1 \-/
| /----\ | | /----\ |
+---| |---+ +---| |---+
\----/ \----/
A | A |
| | | |
| | | |
| | +------------+ | |
| | | D3 | | |
| | /-\ /-\ | |
| +----->| | 3-1-1 | |-------+ |
+---------| | 3-2-1 | |<---------+
\-/ \-/
| |
+------------+
Figure 7: A Network Topology Example
图7：网络拓扑示例
The corresponding instance data tree is depicted in Figure 8:
对应的实例数据树如图8所示：
{
"ietf-network:networks": {
"network": [
{
"network-types": {
},
"network-id": "otn-hc",
"node": [
{
"node-id": "D1",
"termination-point": [
{
"tp-id": "1-0-1"
},
{
"tp-id": "1-2-1"
},
{
"tp-id": "1-3-1"
}
]
},
{
"node-id": "D2",
"termination-point": [
{
"tp-id": "2-0-1"
},
{
"tp-id": "2-1-1"
},
{
"tp-id": "2-3-1"
}
]
},
{
"ietf-network:networks": {
"network": [
{
"network-types": {
},
"network-id": "otn-hc",
"node": [
{
"node-id": "D1",
"termination-point": [
{
"tp-id": "1-0-1"
},
{
"tp-id": "1-2-1"
},
{
"tp-id": "1-3-1"
}
]
},
{
"node-id": "D2",
"termination-point": [
{
"tp-id": "2-0-1"
},
{
"tp-id": "2-1-1"
},
{
"tp-id": "2-3-1"
}
]
},
{
"node-id": "D3",
"termination-point": [
{
"tp-id": "3-1-1"
},
{
"tp-id": "3-2-1"
}
]
}
],
"ietf-network-topology:link": [
{
"link-id": "D1,1-2-1,D2,2-1-1",
"source": {
"source-node": "D1",
"source-tp": "1-2-1"
}
"destination": {
"dest-node": "D2",
"dest-tp": "2-1-1"
}
},
{
"link-id": "D2,2-1-1,D1,1-2-1",
"source": {
"source-node": "D2",
"source-tp": "2-1-1"
}
"destination": {
"dest-node": "D1",
"dest-tp": "1-2-1"
}
},
{
"link-id": "D1,1-3-1,D3,3-1-1",
"source": {
"source-node": "D1",
"source-tp": "1-3-1"
}
"destination": {
"dest-node": "D3",
"dest-tp": "3-1-1"
}
},
{
"node-id": "D3",
"termination-point": [
{
"tp-id": "3-1-1"
},
{
"tp-id": "3-2-1"
}
]
}
],
"ietf-network-topology:link": [
{
"link-id": "D1,1-2-1,D2,2-1-1",
"source": {
"source-node": "D1",
"source-tp": "1-2-1"
}
"destination": {
"dest-node": "D2",
"dest-tp": "2-1-1"
}
},
{
"link-id": "D2,2-1-1,D1,1-2-1",
"source": {
"source-node": "D2",
"source-tp": "2-1-1"
}
"destination": {
"dest-node": "D1",
"dest-tp": "1-2-1"
}
},
{
"link-id": "D1,1-3-1,D3,3-1-1",
"source": {
"source-node": "D1",
"source-tp": "1-3-1"
}
"destination": {
"dest-node": "D3",
"dest-tp": "3-1-1"
}
},
{
"link-id": "D3,3-1-1,D1,1-3-1",
"source": {
"source-node": "D3",
"source-tp": "3-1-1"
}
"destination": {
"dest-node": "D1",
"dest-tp": "1-3-1"
}
},
{
"link-id": "D2,2-3-1,D3,3-2-1",
"source": {
"source-node": "D2",
"source-tp": "2-3-1"
}
"destination": {
"dest-node": "D3",
"dest-tp": "3-2-1"
}
},
{
"link-id": "D3,3-2-1,D2,2-3-1",
"source": {
"source-node": "D3",
"source-tp": "3-2-1"
}
"destination": {
"dest-node": "D2",
"dest-tp": "2-3-1"
}
}
]
}
]
}
}
{
"link-id": "D3,3-1-1,D1,1-3-1",
"source": {
"source-node": "D3",
"source-tp": "3-1-1"
}
"destination": {
"dest-node": "D1",
"dest-tp": "1-3-1"
}
},
{
"link-id": "D2,2-3-1,D3,3-2-1",
"source": {
"source-node": "D2",
"source-tp": "2-3-1"
}
"destination": {
"dest-node": "D3",
"dest-tp": "3-2-1"
}
},
{
"link-id": "D3,3-2-1,D2,2-3-1",
"source": {
"source-node": "D3",
"source-tp": "3-2-1"
}
"destination": {
"dest-node": "D2",
"dest-tp": "2-3-1"
}
}
]
}
]
}
}
Figure 8: Instance Data Tree
图8：实例数据树
Acknowledgments
致谢
We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Alia Atlas, Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Robert Wilton, Qin Wu, and Xian Zhang.
我们希望感谢Alia Atlas、Andy Bierman、Martin Bjorklund、Igor Bryskin、Benoit Claise、Susan Hares、Ladislav Lhotka、Carlos Pignataro、Juergen Schoenwaeld、Robert Wilton、Qin Wu和Xian Zhang提供的有益贡献、意见和建议。
Contributors
贡献者
More people contributed to the data model presented in this paper than can be listed in the "Authors' Addresses" section. Additional contributors include:
本文中提供的数据模型中贡献的人数超过了“作者地址”一节中列出的人数。其他贡献者包括：
o Vishnu Pavan Beeram, Juniper
o 毗瑟奴-帕万-比拉姆，杜松
o Ken Gray, Cisco
o 肯格雷，思科
o Tom Nadeau, Brocade
o 汤姆·纳多，博科
o Tony Tkacik
o 托尼·特卡奇克
o Kent Watsen, Juniper
o 肯特沃特森，杜松
o Aleksandr Zhdankin, Cisco
o Aleksandr Zhdankin，思科
Authors' Addresses
作者地址
Alexander Clemm Huawei USA - Futurewei Technologies Inc. Santa Clara, CA United States of America
Alexander Clemm Huawei USA-美国加利福尼亚州圣克拉拉市Futurewi Technologies Inc.美国
Email: ludwig@clemm.org, alexander.clemm@huawei.com
Email: ludwig@clemm.org, alexander.clemm@huawei.com
Jan Medved Cisco
简·梅德维德·思科
Email: jmedved@cisco.com
Email: jmedved@cisco.com
Robert Varga Pantheon Technologies SRO
罗伯特·瓦尔加万神殿科技有限公司
Email: robert.varga@pantheon.tech
Email: robert.varga@pantheon.tech
Nitin Bahadur Bracket Computing
Nitin Bahadur括号计算
Email: nitin_bahadur@yahoo.com
Email: nitin_bahadur@yahoo.com
Hariharan Ananthakrishnan Packet Design
Hariharan-Ananthakrishnan数据包设计
Email: hari@packetdesign.com
Email: hari@packetdesign.com
Xufeng Liu Jabil
徐峰刘捷普
Email: xufeng.liu.ietf@gmail.com
Email: xufeng.liu.ietf@gmail.com