Internet Engineering Task Force (IETF) Y. Lee
Request for Comments: 8454 Huawei
Category: Informational S. Belotti
ISSN: 2070-1721 Nokia
D. Dhody
Huawei
D. Ceccarelli
Ericsson
B. Yoon
ETRI
September 2018
Internet Engineering Task Force (IETF) Y. Lee
Request for Comments: 8454 Huawei
Category: Informational S. Belotti
ISSN: 2070-1721 Nokia
D. Dhody
Huawei
D. Ceccarelli
Ericsson
B. Yoon
ETRI
September 2018
Information Model for Abstraction and Control of TE Networks (ACTN)
TE网络抽象和控制的信息模型（ACTN）
Abstract
摘要
This document provides an information model for Abstraction and Control of TE Networks (ACTN).
本文件为TE网络（ACTN）的抽象和控制提供了一个信息模型。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8454.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8454.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. ACTN Common Interfaces Information Model . . . . . . . . . . 5
3. Virtual Network Primitives . . . . . . . . . . . . . . . . . 6
3.1. VN Instantiate . . . . . . . . . . . . . . . . . . . . . 7
3.2. VN Modify . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. VN Delete . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. VN Update . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. VN Compute . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. VN Query . . . . . . . . . . . . . . . . . . . . . . . . 8
4. TE Primitives . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. TE Instantiate . . . . . . . . . . . . . . . . . . . . . 9
4.2. TE Modify . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. TE Delete . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. TE Topology Update (for TE Resources) . . . . . . . . . . 9
4.5. Path Compute . . . . . . . . . . . . . . . . . . . . . . 10
5. VN Objects . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. VN Identifier . . . . . . . . . . . . . . . . . . . . . . 11
5.2. VN Service Characteristics . . . . . . . . . . . . . . . 11
5.3. VN Endpoint . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. VN Objective Function . . . . . . . . . . . . . . . . . . 14
5.5. VN Action Status . . . . . . . . . . . . . . . . . . . . 14
5.6. VN Topology . . . . . . . . . . . . . . . . . . . . . . . 15
5.7. VN Member . . . . . . . . . . . . . . . . . . . . . . . . 15
5.7.1. VN Computed Path . . . . . . . . . . . . . . . . . . 15
5.7.2. VN Service Preference . . . . . . . . . . . . . . . . 16
6. TE Objects . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. TE Tunnel Characteristics . . . . . . . . . . . . . . . . 17
7. Mapping of VN Primitives with VN Objects . . . . . . . . . . 19
8. Mapping of TE Primitives with TE Objects . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. ACTN Common Interfaces Information Model . . . . . . . . . . 5
3. Virtual Network Primitives . . . . . . . . . . . . . . . . . 6
3.1. VN Instantiate . . . . . . . . . . . . . . . . . . . . . 7
3.2. VN Modify . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. VN Delete . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. VN Update . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. VN Compute . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. VN Query . . . . . . . . . . . . . . . . . . . . . . . . 8
4. TE Primitives . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. TE Instantiate . . . . . . . . . . . . . . . . . . . . . 9
4.2. TE Modify . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. TE Delete . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. TE Topology Update (for TE Resources) . . . . . . . . . . 9
4.5. Path Compute . . . . . . . . . . . . . . . . . . . . . . 10
5. VN Objects . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. VN Identifier . . . . . . . . . . . . . . . . . . . . . . 11
5.2. VN Service Characteristics . . . . . . . . . . . . . . . 11
5.3. VN Endpoint . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. VN Objective Function . . . . . . . . . . . . . . . . . . 14
5.5. VN Action Status . . . . . . . . . . . . . . . . . . . . 14
5.6. VN Topology . . . . . . . . . . . . . . . . . . . . . . . 15
5.7. VN Member . . . . . . . . . . . . . . . . . . . . . . . . 15
5.7.1. VN Computed Path . . . . . . . . . . . . . . . . . . 15
5.7.2. VN Service Preference . . . . . . . . . . . . . . . . 16
6. TE Objects . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. TE Tunnel Characteristics . . . . . . . . . . . . . . . . 17
7. Mapping of VN Primitives with VN Objects . . . . . . . . . . 19
8. Mapping of TE Primitives with TE Objects . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
This document provides an information model for Abstraction and Control of TE Networks (ACTN). The information model described in this document covers the interface requirements identified in the ACTN Framework document [RFC8453].
本文件为TE网络（ACTN）的抽象和控制提供了一个信息模型。本文件中描述的信息模型涵盖了ACTN框架文件[RFC8453]中确定的接口需求。
The ACTN reference architecture [RFC8453] identifies a three-tier control hierarchy comprising the following as depicted in Figure 1:
ACTN参考体系结构[RFC8453]确定了三层控制层次结构，如图1所示：
o Customer Network Controllers (CNCs) o Multi-Domain Service Coordinator (MDSC) o Provisioning Network Controllers (PNCs)
o 客户网络控制器（CNC）o多域服务协调员（MDSC）o资源调配网络控制器（PNC）
+-------+ +-------+ +-------+
| CNC-A | | CNC-B | | CNC-C |
+-------+ +-------+ +-------+
\ | /
------------ | CMI -------------
\ | /
+----------------------+
| MDSC |
+----------------------+
/ | \
------------ | MPI -------------
/ | \
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
+-------+ +-------+ +-------+
| CNC-A | | CNC-B | | CNC-C |
+-------+ +-------+ +-------+
\ | /
------------ | CMI -------------
\ | /
+----------------------+
| MDSC |
+----------------------+
/ | \
------------ | MPI -------------
/ | \
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
Figure 1: A Three-Tier ACTN Control Hierarchy
图1：三层ACTN控制层次结构
The two interfaces with respect to the MDSC, one north of the MDSC and the other south of the MDSC, are referred to as "CMI" (CNC-MDSC Interface) and "MPI" (MDSC-PNC Interface), respectively. This document models these two interfaces and derivative interfaces thereof (e.g., MDSC-to-MDSC in a hierarchy of MDSCs) as a single common interface.
MDSC的两个接口，一个位于MDSC北部，另一个位于MDSC南部，分别称为“CMI”（CNC-MDSC接口）和“MPI”（MDSC-PNC接口）。本文档将这两个接口及其衍生接口（例如，MDSC层次结构中的MDSC到MDSC）建模为单个公共接口。
The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)" are defined in [RFC8453]. Other key terms and concepts, for example, "abstraction", can be found in [RFC7926].
[RFC8453]中定义了术语“虚拟网络（VN）”和“虚拟网络服务（VNS）”。其他关键术语和概念，例如“抽象”，可在[RFC7926]中找到。
This section provides an ACTN common interface information model to describe primitives, objects, their properties (represented as attributes), their relationships, and the resources for the service applications needed in the ACTN context.
本节提供了一个ACTN公共接口信息模型，用于描述原语、对象、它们的属性（表示为属性）、它们的关系以及ACTN上下文中所需的服务应用程序的资源。
The standard interface is described between a client controller and a server controller. A client-server relationship is recursive between a CNC and an MDSC and between an MDSC and a PNC. In the CMI, the client is a CNC while the server is an MDSC. In the MPI, the client is an MDSC and the server is a PNC. There may also be MDSC-MDSC interfaces that need to be supported. This may arise in a hierarchy of MDSCs in which workloads may need to be partitioned to multiple MDSCs.
客户机控制器和服务器控制器之间描述了标准接口。CNC和MDSC之间以及MDSC和PNC之间的客户机-服务器关系是递归的。在CMI中，客户端是CNC，而服务器是MDSC。在MPI中，客户端是MDSC，服务器是PNC。也可能存在需要支持的MDSC-MDSC接口。这可能出现在MDSC的层次结构中，其中工作负载可能需要划分到多个MDSC。
Basic primitives (messages) are required between the CNC-MDSC and MDSC-PNC controllers. These primitives can then be used to support different ACTN network control functions like network topology requests/queries, VN service requests, path computation and connection control, VN service policy negotiation, enforcement, routing options, etc.
CNC-MDSC和MDSC-PNC控制器之间需要基本原语（消息）。然后，这些原语可用于支持不同的ACTN网络控制功能，如网络拓扑请求/查询、VN服务请求、路径计算和连接控制、VN服务策略协商、实施、路由选项等。
There are two different types of primitives depending on the type of interface:
根据接口的类型，有两种不同类型的基本体：
o Virtual Network primitives at CMI o Traffic Engineering primitives at MPI
o CMI的虚拟网络原语MPI的流量工程原语
As well described in [RFC8453], at the CMI level, there is no need for detailed TE information since the basic functionality is to translate customer service information into VNS operation.
正如[RFC8453]中所述，在CMI级别，不需要详细的TE信息，因为基本功能是将客户服务信息转换为VNS操作。
At the MPI level, MDSC has the main scope for multi-domain coordination and creation of a single end-to-end (E2E) abstracted network view that is strictly related to TE information.
在MPI级别，MDSC主要负责多域协调和创建与TE信息严格相关的单端到端（E2E）抽象网络视图。
As for topology, this document employs two types of topology.
对于拓扑，本文档采用两种类型的拓扑。
o The first type is referred to as "virtual network topology" and is associated with a VN. Virtual network topology is a customized topology for view and control by the customer. See Section 3.1 for details.
o 第一种类型称为“虚拟网络拓扑”，与VN关联。虚拟网络拓扑是供客户查看和控制的自定义拓扑。详见第3.1节。
o The second type is referred to as "TE topology" and is associated with provider network operation on which we can apply policy to obtain the required level of abstraction to represent the underlying physical network topology.
o 第二种类型称为“TE拓扑”，与提供商网络操作相关，我们可以在其上应用策略以获得表示底层物理网络拓扑所需的抽象级别。
This section provides a list of main VN primitives related to VNs and that are necessary to satisfy the ACTN requirements specified in [ACTN-REQ].
本节提供了与VN相关的主要VN原语列表，这些原语是满足[ACTN-REQ]中规定的ACTN要求所必需的。
The following VN Action primitives are supported:
支持以下VN操作原语：
o VN Instantiate
o VN实例化
o VN Modify
o VN修改
o VN Delete
o 删除
o VN Update
o VN更新
o VN Path Compute
o 路径计算
o VN Query
o VN查询
VN Action is an object describing the main VN primitives.
VN操作是一个描述主要VN原语的对象。
VN Action can assume one of the mentioned above primitives values.
VN操作可以采用上述原语值之一。
<VN Action> ::= <VN Instantiate> |
<VN Action> ::= <VN Instantiate> |
<VN Modify> |
<VN修改>|
<VN Delete> |
<VN删除>|
<VN Update> |
<VN更新>|
<VN Path Compute> |
<VN路径计算>|
<VN Query>
<VN查询>
All these actions will solely happen at CMI level between CNC and MDSC.
所有这些行动将仅在CNC和MDSC之间的CMI级别进行。
VN Instantiate refers to an action from customers/applications to request the creation of VNs. VN Instantiate is for CNC-to-MDSC communication. Depending on the agreement between client and provider, VN instantiate can imply different VN operations. There are two types of VN instantiation:
VN实例化是指客户/应用程序请求创建VN的操作。VN实例化用于CNC到MDSC的通信。根据客户机和提供者之间的协议，VN实例化可能意味着不同的VN操作。有两种类型的VN实例化：
VN Type 1: VN is viewed as a set of edge-to-edge links (VN members).
VN类型1:VN被视为一组边到边链接（VN成员）。
VN Type 2: VN is viewed as a VN-topology comprising virtual nodes and virtual links.
VN类型2：VN被视为包含虚拟节点和虚拟链路的VN拓扑。
Please see [RFC8453] for full details regarding the types of VN.
有关VN类型的详细信息，请参见[RFC8453]。
VN Modify refers to an action issued from customers/applications to modify an existing VN (i.e., an instantiated VN). VN Modify is for CNC-to-MDSC communication.
VN Modify是指客户/应用程序发出的修改现有VN（即实例化的VN）的操作。VN Modify用于CNC到MDSC的通信。
VN Modify, depending of the type of VN instantiated, can be:
根据实例化的VN类型，VN Modify可以是：
1. a modification of the characteristics of VN members (edge-to-edge links) in the case of VN Type 1, or
1. 在VN类型1的情况下，修改VN成员的特性（边到边链路），或
2. a modification of an existing virtual topology (e.g., adding/ deleting virtual nodes/links) in the case of VN Type 2.
2. 在VN类型2的情况下，对现有虚拟拓扑的修改（例如，添加/删除虚拟节点/链路）。
VN Delete refers to an action issued from customers/applications to delete an existing VN. VN Delete is for CNC-to-MDSC communication.
VN删除是指客户/应用程序发出的删除现有VN的操作。VN Delete用于CNC到MDSC的通信。
"VN Update" refers to any update to the VN that needs to be updated to the customers. VN Update is MDSC-to-CNC communication. VN Update fulfills a push model at the CMI level, making customers aware of any specific changes in the topology details related to the instantiated VN.
“VN更新”是指需要向客户更新的任何VN更新。VN更新是MDSC到CNC的通信。VN更新实现了CMI级别的推送模型，使客户了解与实例化VN相关的拓扑细节中的任何特定更改。
VN Update, depending of the type of VN instantiated, can be:
根据实例化的VN类型，VN更新可以是：
1. an update of VN members (edge-to-edge links) in case of VN Type 1, or
1. 对于VN类型1，更新VN成员（边到边链接），或
2. an update of virtual topology in case of VN Type 2.
2. VN类型2情况下虚拟拓扑的更新。
The connection-related information (e.g., Label Switched Paths (LSPs)) update association with VNs will be part of the "translation" function that happens in MDSC to map/translate VN request into TE semantics. This information will be provided in case the customer optionally wants to have more-detailed TE information associated with the instantiated VN.
与VN的连接相关信息（例如，标签交换路径（LSP））更新关联将是MDSC中用于将VN请求映射/转换为TE语义的“转换”功能的一部分。如果客户希望获得与实例化VN相关的更详细的TE信息，则将提供此信息。
VN Compute consists of a Request and Reply. "VN Compute Request" refers to an action from customers/applications to request a VN computation.
VN计算由请求和应答组成。“VN计算请求”是指客户/应用程序请求VN计算的操作。
"VN Compute Reply" refers to the reply in response to VN Compute Request.
“VN计算回复”是指响应VN计算请求的回复。
A VN Compute Request/Reply is to be differentiated from a VN Instantiate. The purpose of VN Compute is a priori exploration to compute network resources availability and getting a possible VN view in which path details can be specified matching customer/applications constraints. This a priori exploration may not guarantee the availability of the computed network resources at the time of instantiation.
VN计算请求/应答与VN实例化不同。VN Compute的目的是对网络资源可用性进行先验探索，并获得一个可能的VN视图，在该视图中，可以根据客户/应用程序约束指定路径详细信息。这种先验探索可能无法保证实例化时计算的网络资源的可用性。
"VN Query" refers to an inquiry pertaining to a VN that has already been instantiated. VN Query fulfills a pull model that permits getting a topology view.
“VN查询”是指与已实例化的VN相关的查询。VN查询实现了允许获取拓扑视图的拉模型。
"VN Query Reply" refers to the reply in response to a VN Query. The topology view returned by a VN Query Reply would be consistent with the topology type instantiated for any specific VN.
“VN查询应答”是指对VN查询的应答。VN查询回复返回的拓扑视图将与为任何特定VN实例化的拓扑类型一致。
This section provides a list of the main TE primitives necessary to satisfy ACTN requirements specified in [ACTN-REQ] related to typical TE operations supported at the MPI level.
本节提供了满足[ACTN-REQ]中规定的与MPI级支持的典型TE操作相关的ACTN要求所需的主要TE原语列表。
The TE action primitives defined in this section should be supported at the MPI consistently with the type of topology defined at the CMI.
MPI应与CMI定义的拓扑类型一致地支持本节中定义的TE操作原语。
The following TE action primitives are supported:
支持以下TE操作原语：
o TE Instantiate/Modify/Delete
o 实例化/修改/删除
o TE Topology Update (see Section 4.4. for the description)
o TE拓扑更新（有关说明，请参见第4.4节）
o Path Compute
o 路径计算
TE Action is an object describing the main TE primitives.
TE Action是一个描述主要TE原语的对象。
TE Action can assume one of the mentioned above primitives values.
TE Action可以采用上述基本值之一。
<TE Action> ::= <TE Instantiate> |
<TE Action> ::= <TE Instantiate> |
<TE Modify> |
<TE修改>|
<TE Delete> |
<TE删除>|
<TE Topology Update> |
<Path Compute> |
<TE Topology Update> |
<Path Compute> |
All these actions will solely happen at MPI level between MDSC and PNC.
所有这些操作将仅在MDSC和PNC之间的MPI级别上进行。
"TE Instantiate" refers to an action issued from MDSC to PNC to instantiate new TE tunnels.
“TE实例化”是指MDSC向PNC发出的实例化新TE隧道的操作。
"TE Modify" refers to an action issued from MDSC to PNC to modify existing TE tunnels.
“TE修改”是指MDSC向PNC发布的修改现有TE隧道的行动。
"TE Delete" refers to an action issued from MDSC to PNC to delete existing TE tunnels.
“TE删除”是指MDSC向PNC发布的删除现有TE隧道的行动。
TE Topology Update is a primitive specifically related to MPI used to provide a TE resource update between any domain controller and MDSC regarding the entire content of any actual TE topology of a domain controller or an abstracted filtered view of TE topology depending on negotiated policy.
TE Topology Update是一个与MPI特别相关的原语，用于在任何域控制器和MDSC之间提供关于域控制器的任何实际TE拓扑的全部内容的TE资源更新，或根据协商策略提供TE拓扑的抽象过滤视图。
See [TE-TOPO] for detailed YANG implementation of TE topology update.
有关TE拓扑更新的详细实现，请参见[TE-TOPO]。
<TE Topology Update> ::= <TE-topology-list>
<TE Topology Update> ::= <TE-topology-list>
<TE-topology-list> ::= <TE-topology> [<TE-topology-list>]
<TE-topology-list> ::= <TE-topology> [<TE-topology-list>]
<TE-topology> ::= [<Abstraction>] <TE-Topology-identifier> <Node-
list> <Link-list>
<Node-list> ::= <Node>[<Node-list>]
<TE-topology> ::= [<Abstraction>] <TE-Topology-identifier> <Node-
list> <Link-list>
<Node-list> ::= <Node>[<Node-list>]
<Node> ::= <Node> <TE Termination Point-list>
<Node> ::= <Node> <TE Termination Point-list>
<TE Termination Point-list> ::= <TE Termination Point> [<TE-
Termination Point-list>]
<TE Termination Point-list> ::= <TE Termination Point> [<TE-
Termination Point-list>]
<Link-list> ::= <Link>[<Link-list>]
<Link-list> ::= <Link>[<Link-list>]
Where
哪里
Abstraction provides information on the level of abstraction (as determined a priori).
抽象提供了关于抽象级别的信息（如预先确定的）。
TE-topology-identifier is an identifier that identifies a specific te-topology, e.g., te-types:te-topology-id [TE-TOPO].
TE拓扑标识符是标识特定TE拓扑的标识符，例如TE类型：TE拓扑id[TE-TOPO]。
Node-list is detailed information related to a specific node belonging to a te-topology, e.g., te-node-attributes [TE-TOPO].
节点列表是与属于te拓扑的特定节点相关的详细信息，例如te节点属性[te-TOPO]。
Link-list is information related to the specific link related belonging to a te-topology, e.g., te-link-attributes [TE-TOPO].
链路列表是与属于te拓扑的特定链路相关的信息，例如te链路属性[te-TOPO]。
TE Termination Point-list is detailed information associated with the termination points of a te-link related to a specific node, e.g., interface-switching-capability [TE-TOPO].
TE终止点列表是与特定节点相关的TE链路的终止点相关的详细信息，例如，接口交换能力[TE-TOPO]。
Path Compute consists of Request and Reply. "Path Compute Request" refers to an action from MDSC to PNC to request a path computation.
路径计算由请求和应答组成。“路径计算请求”是指从MDSC到PNC请求路径计算的操作。
"Path Compute Reply" refers to the reply in response to the Path Compute Request.
“路径计算回复”是指响应路径计算请求的回复。
The context of Path Compute is described in [Path-Compute].
路径计算的上下文在[Path Compute]中描述。
This section provides a list of objects associated to VN action primitives.
本节提供与VN操作原语关联的对象列表。
A VN Identifier is a unique identifier of the VN.
VN标识符是VN的唯一标识符。
VN Service Characteristics describes the customer/application requirements against the VNs to be instantiated.
VN服务特征描述了针对要实例化的VN的客户/应用程序需求。
<VN Service Characteristics> ::= <VN Connectivity Type>
<VN Service Characteristics> ::= <VN Connectivity Type>
<VN Directionality>
<VN方向性>
(<VN Traffic Matrix>...)
（<VN流量矩阵>…）
<VN Survivability>
<VN生存能力>
Where
哪里
<VN Connectivity Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>|<Multi-
destination>
<VN Connectivity Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>|<Multi-
destination>
The Connectivity Type identifies the type of required VN Service. In addition to the classical types of services (e.g., P2P/P2MP, etc.), ACTN defines the "multi-destination" service that is a new P2P service where the endpoints are not fixed. They can be chosen among a list of preconfigured endpoints or dynamically provided by the CNC.
连接类型标识所需VN服务的类型。除了传统类型的服务（例如，P2P/P2MP等），ACTN还定义了“多目的地”服务，这是一种端点不固定的新P2P服务。它们可以从预先配置的端点列表中选择，也可以由CNC动态提供。
VN Directionality indicates if a VN is unidirectional or bidirectional. This implies that each VN member that belongs to the VN has the same directionality as the VN.
VN方向性表示VN是单向的还是双向的。这意味着属于VN的每个VN成员都具有与VN相同的方向性。
<VN Traffic Matrix> ::= <Bandwidth>
<VN Traffic Matrix> ::= <Bandwidth>
[<VN Constraints>]
[<VN约束>]
The VN Traffic Matrix represents the traffic matrix parameters for the required service connectivity. Bandwidth is a mandatory parameter, and a number of optional constraints can be specified in the VN Constraints (e.g., diversity, cost). They can include objective functions and TE metric bounds as specified in [RFC5541].
VN流量矩阵表示所需服务连接的流量矩阵参数。带宽是一个强制性参数，可以在VN约束中指定许多可选约束（例如，多样性、成本）。它们可以包括[RFC5541]中规定的目标函数和TE度量界限。
Further details on the VN constraints are specified below:
有关VN约束的更多详细信息如下：
<VN Constraints> ::= [<Layer Protocol>]
[<Diversity>]
<VN Constraints> ::= [<Layer Protocol>]
[<Diversity>]
( <Metric> | <VN Objective Function> )
( <Metric> | <VN Objective Function> )
Where:
哪里：
Layer Protocol identifies the layer topology at which the VN service is requested. It could be, for example, MPLS, Optical Data Unit (ODU), and Optical Channel (OCh).
层协议标识请求VN服务的层拓扑。例如，它可以是MPLS、光数据单元（ODU）和光信道（OCh）。
Diversity allows asking for diversity constraints for a VN Instantiate/Modify or a VN Path Compute. For example, a new VN or a path is requested in total diversity from an existing one (e.g., diversity exclusion).
多样性允许为VN实例化/修改或VN路径计算请求多样性约束。例如，从现有的VN或路径请求一个新的VN或路径（例如，分集排除）。
<Diversity> ::= (<VN-exclusion> (<VN-id>...)) |
<Diversity> ::= (<VN-exclusion> (<VN-id>...)) |
(<VN-Member-exclusion> (<VN-Member-id>...))
(<VN-Member-exclusion> (<VN-Member-id>...))
Metric can include all the Metrics (cost, delay, delay variation, latency) and bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471].
指标可以包括[RFC3630]和[RFC7471]定义和引用的所有指标（成本、延迟、延迟变化、延迟）和带宽利用率参数。
As for VN Objective Function, see Section 5.4.
关于VN目标函数，见第5.4节。
VN Survivability describes all attributes related to the VN recovery level and its survivability policy enforced by the customers/ applications.
VN生存性描述了与VN恢复级别及其由客户/应用程序实施的生存性策略相关的所有属性。
<VN Survivability> ::= <VN Recovery Level>
<VN Survivability> ::= <VN Recovery Level>
[<VN Tunnel Recovery Level>]
[<VN隧道恢复水平>]
[<VN Survivability Policy>] Where:
[<VN生存能力策略>]其中：
VN Recovery Level is a value representing the requested level of resiliency required against the VN. The following values are defined:
VN恢复级别是一个值，表示针对VN所需的请求恢复级别。定义了以下值：
o Unprotected VN
o 无保护VN
o VN with per tunnel recovery: The recovery level is defined against the tunnels composing the VN, and it is specified in the VN Tunnel Recovery Level.
o 每个隧道恢复的VN：恢复级别根据构成VN的隧道定义，并在VN隧道恢复级别中指定。
<VN Tunnel Recovery Level> ::= <0:1>|<1+1>|<1:1>|<1:N>|<M:N>|
<On the fly restoration>
<VN Tunnel Recovery Level> ::= <0:1>|<1+1>|<1:1>|<1:N>|<M:N>|
<On the fly restoration>
The VN Tunnel Recovery Level indicates the type of protection or restoration mechanism applied to the VN. It augments the recovery types defined in [RFC4427].
VN隧道恢复级别表示应用于VN的保护或恢复机制的类型。它扩展了[RFC4427]中定义的恢复类型。
<VN Survivability Policy> ::= [<Local Reroute Allowed>]
<VN Survivability Policy> ::= [<Local Reroute Allowed>]
[<Domain Preference>]
[<Domain Preference>]
[<Push Allowed>]
[<Push-Allowed>]
[<Incremental Update>]
[<Incremental Update>]
Where:
哪里：
Local Reroute Allowed is a delegation policy to the Server on whether or not to allow a local reroute fix upon a failure of the primary LSP.
Local Reroute Allowed（允许本地重新路由）是服务器的委派策略，用于在主LSP出现故障时是否允许本地重新路由修复。
Domain Preference is only applied on the MPI where the MDSC (client) provides a domain preference to each PNC (server), e.g., when an inter-domain link fails, then PNC can choose the alternative peering with this info.
域首选项仅适用于MDSC（客户端）向每个PNC（服务器）提供域首选项的MPI，例如，当域间链接失败时，PNC可以使用此信息选择替代对等。
Push Allowed is a policy that allows a server to trigger an updated VN topology upon failure without an explicit request from the client. Push action can be set as default unless otherwise specified.
允许推送是一种策略，允许服务器在发生故障时触发更新的VN拓扑，而无需客户端发出明确请求。除非另有规定，推送动作可以设置为默认值。
Incremental Update is another policy that triggers an incremental update from the server since the last period of update. Incremental update can be set as default unless otherwise specified.
增量更新是另一种策略，它从上次更新期间开始从服务器触发增量更新。除非另有规定，否则可以将增量更新设置为默认值。
VN End-Point Object describes the VN's customer endpoint characteristics.
VN端点对象描述VN的客户端点特征。
<VN End-Point> ::= (<Access Point Identifier>
<VN End-Point> ::= (<Access Point Identifier>
[<Access Link Capability>] [<Source Indicator>])...
[<Access Link Capability>][<Source Indicator>]）。。。
Where:
哪里：
Access Point Identifier represents a unique identifier of the client endpoint. They are used by the customer to ask for the setup of a virtual network instantiation. A VN End-Point is defined against each AP in the network and is shared between customer and provider. Both the customer and the provider will map it against their own physical resources.
访问点标识符表示客户端端点的唯一标识符。客户使用它们来请求设置虚拟网络实例。针对网络中的每个AP定义VN端点，并在客户和提供商之间共享。客户和提供商都将根据自己的物理资源进行映射。
Access Link Capability identifies the capabilities of the access link related to the given access point (e.g., max-bandwidth, bandwidth availability, etc.).
接入链路能力识别与给定接入点相关的接入链路的能力（例如，最大带宽、带宽可用性等）。
Source Indicator indicates whether or not an endpoint is the source.
源指示符指示端点是否为源。
The VN Objective Function applies to each VN member (i.e., each E2E tunnel) of a VN.
VN目标函数适用于VN的每个VN成员（即每个E2E隧道）。
The VN Objective Function can reuse objective functions defined in Section 4 of [RFC5541].
VN目标函数可以重用[RFC5541]第4节中定义的目标函数。
For a single path computation, the following objective functions are defined:
对于单路径计算，定义了以下目标函数：
o MCP is the Minimum Cost Path with respect to a specific metric (e.g., shortest path).
o MCP是关于特定指标的最小成本路径（例如，最短路径）。
o MLP is the Minimum Load Path, meaning find a path composted by te-link least loaded.
o MLP是最小负载路径，这意味着找到一条由te链路组成的负载最小的路径。
o MBP is the Maximum residual Bandwidth Path.
o MBP是最大剩余带宽路径。
For a concurrent path computation, the following objective functions are defined:
对于并发路径计算，定义了以下目标函数：
o MBC is to Minimize aggregate Bandwidth Consumption.
o MBC是最小化总带宽消耗。
o MLL is to Minimize the Load of the most loaded Link.
o MLL是使负载最大的链路的负载最小化。
o MCC is to Minimize the Cumulative Cost of a set of paths.
o MCC旨在最小化一组路径的累积成本。
VN Action Status is the status indicator whether or not the VN has been successfully instantiated, modified, or deleted in the server network in response to a particular VN action.
VN Action Status是一个状态指示器，用于指示是否已在服务器网络中成功实例化、修改或删除VN以响应特定的VN操作。
Note that this action status object can be implicitly indicated and, thus, not included in any of the VN primitives discussed in Section 3.
请注意，此操作状态对象可以隐式指示，因此不包括在第3节中讨论的任何VN原语中。
When a VN is seen by the customer as a topology, it is referred to as "VN topology". This is associated with VN Type 2, which is composed of virtual nodes and virtual links.
当客户将VN视为拓扑时，它被称为“VN拓扑”。这与VN类型2相关，它由虚拟节点和虚拟链路组成。
<VN Topology> ::= <Virtual node list> <Virtual link list>
<VN Topology> ::= <Virtual node list> <Virtual link list>
<Virtual node list> ::= <Virtual node> [<Virtual node list>]
<Virtual node list> ::= <Virtual node> [<Virtual node list>]
<Virtual link list> :: = <Virtual link> [<Virtual link list>]
<Virtual link list> :: = <Virtual link> [<Virtual link list>]
VN Member describes details of a VN Member that is a list of a set of VN Members represented as VN_Member_List.
VN成员描述VN成员的详细信息，VN成员是表示为VN_成员_列表的一组VN成员的列表。
<VN_Member_List> ::= <VN Member> [<VN_Member_List>]
<VN_Member_List> ::= <VN Member> [<VN_Member_List>]
Where <VN Member> ::= <Ingress VN End-Point>
Where <VN Member> ::= <Ingress VN End-Point>
[<VN Associated LSP>]
[<VN相关LSP>]
<Egress VN End-Point>
<出口VN终点>
Ingress VN End-Point is the VN End-Point information for the ingress portion of the AP. See Section 5.3 for VN End-Point details.
入口VN端点是AP入口部分的VN端点信息。有关VN端点的详细信息，请参见第5.3节。
Egress VN End-Point is the VN End-Point information for the egress portion of the AP. See Section 5.3 for VN End-Point details.
出口VN端点是AP的出口部分的VN端点信息。有关VN端点的详细信息，请参见第5.3节。
VN Associated LSP describes the instantiated LSPs in the Provider's network for the VN Type 1. It describes the instantiated LSPs over the VN topology for VN Type 2.
VN关联LSP描述了供应商网络中VN类型1的实例化LSP。它描述了VN类型2在VN拓扑上的实例化LSP。
The VN Computed Path is the list of paths obtained after the VN path computation request from a higher controller. Note that the computed path is to be distinguished from the LSP. When the computed path is signaled in the network (and thus the resource is reserved for that path), it becomes an LSP.
VN计算路径是在从更高控制器请求VN路径计算后获得的路径列表。请注意，计算路径与LSP不同。当计算出的路径在网络中发出信号时（因此为该路径保留资源），它将成为LSP。
<VN Computed Path> ::= (<Path>...)
<VN Computed Path> ::= (<Path>...)
This section provides the VN Service preference. VN Service is defined in Section 2.
本节提供VN服务首选项。第2节定义了VN服务。
<VN Service Preference> ::= [<Location Service Preference >]
<VN Service Preference> ::= [<Location Service Preference >]
[<Client-specific Preference >]
[<Client-specific Preference>]
[<End-Point Dynamic Selection Preference >]
[<终点动态选择首选项>]
Where
哪里
Location Service Preference describes the End-Point Location's (e.g., data centers (DCs)) support for certain Virtual Network Functions (VNFs) (e.g., security function, firewall capability, etc.) and is used to find the path that satisfies the VNF constraint.
位置服务首选项描述端点位置（例如，数据中心（DCs））对某些虚拟网络功能（VNF）（例如，安全功能、防火墙功能等）的支持，并用于查找满足VNF约束的路径。
Client-specific Preference describes any preference related to VNS that an application/client can enforce via CNC towards lower-level controllers. For example, CNC can enforce client-specific preferences, e.g., selection of a destination DC from the set of candidate DCs based on some criteria in the context of Virtual Machine (VM) migration. MSDC/PNC should then provide the DC interconnection that supports the Client-specific Preference.
特定于客户端的首选项描述了应用程序/客户端可通过CNC向较低级别控制器实施的与VNS相关的任何首选项。例如，CNC可以实施特定于客户端的首选项，例如，在虚拟机（VM）迁移的上下文中，根据某些标准从候选DC集中选择目标DC。然后，MSDC/PNC应提供支持客户特定偏好的DC互连。
End-Point Dynamic Selection Preference describes if the endpoint (e.g., DC) can support load-balancing, disaster recovery, or VM migration and so can be part of the selection by MDSC following service Preference enforcement by CNC.
端点动态选择首选项描述端点（例如，DC）是否能够支持负载平衡、灾难恢复或VM迁移，从而在CNC强制实施服务首选项后成为MDSC选择的一部分。
Tunnel Characteristics describes the parameters needed to configure TE tunnel.
隧道特性描述了配置TE隧道所需的参数。
<TE Tunnel Characteristics> ::= [<Tunnel Type>]
<TE Tunnel Characteristics> ::= [<Tunnel Type>]
<Tunnel Id>
<Tunnel Id>
[<Tunnel Layer>]
[<隧道层>]
[<Tunnel end-point>]
[<Tunnel end-point>]
[<Tunnel protection-restoration>]
[<隧道保护修复>]
<Tunnel Constraints>
<隧道约束>
[<Tunnel Optimization>]
[<隧道优化>]
Where
哪里
<Tunnel Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>
<Tunnel Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>
The Tunnel Type identifies the type of required tunnel. In this document, only the P2P model is provided.
隧道类型标识所需隧道的类型。在本文档中，仅提供了P2P模型。
Tunnel Id is the TE tunnel identifier
隧道Id是TE隧道标识符
Tunnel Layer represents the layer technology of the LSPs supporting the tunnel
隧道层表示支持隧道的LSP的层技术
<Tunnel End Points> ::= <Source> <Destination>
<Tunnel End Points> ::= <Source> <Destination>
<Tunnel protection-restoration> ::= <prot 0:1>|<prot 1+1>|<prot
1:1>|<prot 1:N>|prot <M:N>|<restoration>
Tunnel Constraints are the base tunnel configuration constraints
parameters.
<Tunnel protection-restoration> ::= <prot 0:1>|<prot 1+1>|<prot
1:1>|<prot 1:N>|prot <M:N>|<restoration>
Tunnel Constraints are the base tunnel configuration constraints
parameters.
Where <Tunnel Constraints> ::= [<Topology Id>]
Where <Tunnel Constraints> ::= [<Topology Id>]
[<Bandwidth>]
[<Bandwidth>]
[<Disjointness>]
[<disjoint>]
[<SRLG>]
[<SRLG>]
[<Priority>]
[<Priority>]
[<Affinities>]
[<affinity>]
[<Tunnel Optimization>]
[<隧道优化>]
[<Objective Function>]
[<目标函数>]
Topology Id references the topology used to compute the tunnel path.
拓扑Id引用用于计算隧道路径的拓扑。
Bandwidth is the bandwidth used as a parameter in path computation.
带宽是在路径计算中用作参数的带宽。
<Disjointness> ::= <node> | <link> | <srlg>
<Disjointness> ::= <node> | <link> | <srlg>
Disjointness provides the type of resources from which the tunnel has to be disjointed.
脱节性提供了隧道必须脱节的资源类型。
Shared Risk Link Group (SRLG) is a group of physical resources impacted by the same risk from which an E2E tunnel is required to be disjointed.
共享风险链接组（SRLG）是一组受相同风险影响的物理资源，E2E隧道需要从中分离。
<Priority> ::= <Holding Priority> <Setup Priority>
<Priority> ::= <Holding Priority> <Setup Priority>
where
哪里
Setup Priority indicates the level of priority for taking resources from another tunnel [RFC3209].
设置优先级指示从另一个隧道获取资源的优先级[RFC3209]。
Holding Priority indicates the level of priority to hold resources avoiding preemption from another tunnel [RFC3209].
Holding Priority表示保存资源以避免从另一个隧道抢占的优先级级别[RFC3209]。
Affinities represents the structure to validate a link belonging to the path of the tunnel [RFC3209].
亲缘关系表示用于验证属于隧道路径的链接的结构[RFC3209]。
<Tunnel Optimization> ::= <Metric> | <Objective Function>
<Tunnel Optimization> ::= <Metric> | <Objective Function>
Metric can include all the Metrics (cost, delay, delay variation, latency) and bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471].
指标可以包括[RFC3630]和[RFC7471]定义和引用的所有指标（成本、延迟、延迟变化、延迟）和带宽利用率参数。
<Objective Function> ::= <objective function type>
<Objective Function> ::= <objective function type>
<objective function type> ::= <MCP> | <MLP> | <MBP> | <MBC> | <MLL>
| <MCC>
<objective function type> ::= <MCP> | <MLP> | <MBP> | <MBC> | <MLL>
| <MCC>
See Section 5.4 for a description of objective function type.
有关目标函数类型的说明，请参见第5.4节。
This section describes the mapping of VN primitives with VN Objects based on Section 5.
本节描述了基于第5节的VN原语与VN对象的映射。
<VN Instantiate> ::= <VN Service Characteristics>
<VN Instantiate> ::= <VN Service Characteristics>
<VN Member-List>
<VN成员列表>
[<VN Service Preference>]
[<VN服务首选项>]
[<VN Topology>]
[<VN拓扑结构>]
<VN Modify> ::= <VN identifier>
<VN Modify> ::= <VN identifier>
<VN Service Characteristics>
<VN服务特性>
<VN Member-List>
<VN成员列表>
[<VN Service Preference>]
[<VN服务首选项>]
[<VN Topology>]
[<VN拓扑结构>]
<VN Delete> ::= <VN Identifier>
<VN Delete> ::= <VN Identifier>
<VN Update> :: = <VN Identifier>
[<VN Member-List>]
<VN Update> :: = <VN Identifier>
[<VN Member-List>]
[<VN Topology>]
[<VN拓扑结构>]
<VN Path Compute Request> ::= <VN Service Characteristics>
<VN Path Compute Request> ::= <VN Service Characteristics>
<VN Member-List>
<VN成员列表>
[<VN Service Preference>]
[<VN服务首选项>]
<VN Path Compute Reply> ::= <VN Computed Path>
<VN Path Compute Reply> ::= <VN Computed Path>
<VN Query> ::= <VN Identifier>
<VN Query> ::= <VN Identifier>
<VN Query Reply> ::= <VN Identifier>
<VN Query Reply> ::= <VN Identifier>
<VN Associated LSP>
<VN相关LSP>
[<TE Topology Reference>]
[<TE拓扑参考>]
This section describes the mapping of TE primitives with TE Objects based on Section 6.
本节描述了基于第6节的TE原语与TE对象的映射。
<TE Instantiate> ::= <TE Tunnel Characteristics>
<TE Instantiate> ::= <TE Tunnel Characteristics>
<TE Modify> ::= <TE Tunnel Characteristics>
<TE Modify> ::= <TE Tunnel Characteristics>
<TE Delete> ::= <Tunnel Id>
<TE Topology Update> ::= <TE-topology-list>
<TE Delete> ::= <Tunnel Id>
<TE Topology Update> ::= <TE-topology-list>
<Path Compute Request> ::= <TE Tunnel Characteristics>
<Path Compute Request> ::= <TE Tunnel Characteristics>
<Path Compute Reply> ::= <TE Computed Path>
<Path Compute Reply> ::= <TE Computed Path>
<TE Tunnel Characteristics>
<TE隧道特性>
The ACTN information model is not directly relevant when considering potential security issues. Rather, it defines a set of interfaces for TE networks. The underlying protocols, procedures, and implementations used to exchange the information model described in this document will need to secure the request and control of resources with proper authentication and authorization mechanisms. In addition, the data exchanged over the ACTN interfaces discussed in this document requires verification of data integrity. Backup or redundancies should also be available to restore the affected data to its correct state.
在考虑潜在的安全问题时，ACTN信息模型并不直接相关。相反，它为TE网络定义了一组接口。用于交换本文档中描述的信息模型的底层协议、过程和实现需要使用适当的身份验证和授权机制来保护资源的请求和控制。此外，本文件中讨论的通过ACTN接口交换的数据需要验证数据完整性。还应提供备份或冗余，以将受影响的数据恢复到正确的状态。
Implementations of the ACTN framework will have distributed functional components that will exchange an instantiation that adheres to this information model. Implementations should encrypt data that flows between them, especially when they are implemented at remote nodes and irrespective of whether these data flows are on external or internal network interfaces. The information model may contain customer, application, and network data that, for business or privacy reasons, may be considered sensitive. It should be stored only in an encrypted data store.
ACTN框架的实现将具有分布式功能组件，这些组件将交换遵循此信息模型的实例化。实现应该加密在它们之间流动的数据，特别是当它们在远程节点上实现时，不管这些数据流是在外部网络接口上还是在内部网络接口上。信息模型可能包含出于业务或隐私原因可能被视为敏感的客户、应用程序和网络数据。它应该只存储在加密的数据存储中。
The ACTN security discussion is further split into two specific interfaces:
ACTN安全讨论进一步分为两个特定接口：
o Interface between the CNC and MDSC, CNC-MDSC Interface (CMI)
o CNC和MDSC之间的接口，CNC-MDSC接口（CMI）
o Interface between the MDSC and PNC, MDSC-PNC Interface (MPI).
o MDSC和PNC之间的接口，MDSC-PNC接口（MPI）。
See the detailed discussion of the CMI and MPI in Sections 9.1 and 9.2 (respectively) in [RFC8453].
参见[RFC8453]第9.1节和第9.2节（分别）中关于CMI和MPI的详细讨论。
The conclusion is that all data models and protocols used to realize the ACTN information model should have rich security features, as discussed in this section. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific.
结论是，如本节所述，用于实现ACTN信息模型的所有数据模型和协议都应该具有丰富的安全特性。其他安全风险可能仍然存在。因此，特定安全功能和协议的讨论和适用性将在特定于用例和环境的文档中得到更好的描述。
This document has no IANA actions.
本文档没有IANA操作。
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
[RFC8453]Ceccarelli，D.，Ed.和Y.Lee，Ed.，“TE网络的抽象和控制框架（ACTN）”，RFC 8453，DOI 10.17487/RFC8453，2018年8月<https://www.rfc-editor.org/info/rfc8453>.
[ACTN-REQ] Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. Lee, "Requirements for Abstraction and Control of TE Networks", Work in Progress, draft-ietf-teas-actn-requirements-09, March 2018.
[ACTN-REQ]Lee，Y.，Ceccarelli，D.，Miyasaka，T.，Shin，J.，和K.Lee，“TE网络的抽象和控制要求”，在建工程，草案-ietf-teas-ACTN-Requirements-092018年3月。
[Path-Compute] Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma, A., Shi, Y., Vilata, R., and K. Sethuraman, "Yang model for requesting Path Computation", Work in Progress, draft-ietf-teas-yang-path-computation-02, June 2018.
[路径计算]Busi，I.，Belotti，S.，Lopezalvarez，V.，Dios，O.，Sharma，A.，Shi，Y.，Vilata，R.，和K.Sethuraman，“请求路径计算的杨模型”，正在进行中的工作，草案-ietf-teas-Yang-Path-COMPUTION-022018年6月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<https://www.rfc-editor.org/info/rfc3630>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-editor.org/info/rfc4427>.
[RFC4427]Mannie，E.，Ed.和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，DOI 10.17487/RFC4427，2006年3月<https://www.rfc-editor.org/info/rfc4427>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.
[RFC5541]Le Roux，JL.，Vasseur，JP.，和Y.Lee，“路径计算元素通信协议（PCEP）中目标函数的编码”，RFC 5541，DOI 10.17487/RFC55412009年6月<https://www.rfc-editor.org/info/rfc5541>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.
[RFC7471]Giacalone，S.，Ward，D.，Drake，J.，Atlas，A.，和S.Previdi，“OSPF交通工程（TE）度量扩展”，RFC 7471，DOI 10.17487/RFC7471，2015年3月<https://www.rfc-editor.org/info/rfc7471>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, <https://www.rfc-editor.org/info/rfc7926>.
[RFC7926]Farrel，A.，Ed.，Drake，J.，Bitar，N.，Swallow，G.，Ceccarelli，D.，和X.Zhang，“互联流量工程网络之间信息交换的问题陈述和体系结构”，BCP 206，RFC 7926，DOI 10.17487/RFC7926，2016年7月<https://www.rfc-editor.org/info/rfc7926>.
[TE-TOPO] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", Work in Progress, draft-ietf-teas-yang-te-topo-18, June 2018.
[TE-TOPO]Liu，X.，Bryskin，I.，Beeram，V.，Saad，T.，Shah，H.，和O.Dios，“交通工程（TE）拓扑的YANG数据模型”，正在进行的工作，草案-ietf-teas-YANG-TE-TOPO-18，2018年6月。
Contributors
贡献者
Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com
郑浩棉华为技术电子邮件：zhenghaomian@huawei.com
Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com
Xian Zhang华为技术电子邮件：Zhang。xian@huawei.com
Authors' Addresses
作者地址
Young Lee (Editor) Huawei Technologies 5340 Legacy Drive Plano, TX 75023, USA
Young Lee（编辑）华为技术5340 Legacy Drive Plano，德克萨斯州75023，美国
Phone: (469)277-5838 Email: leeyoung@huawei.com
电话：（469）277-5838电子邮件：leeyoung@huawei.com
Sergio Belotti (Editor) Nokia Via Trento, 30 Vimercate, Italy
塞尔吉奥·贝洛蒂（编辑）诺基亚Via Trento，30 Vimercate，意大利
Email: sergio.belotti@nokia.com
Email: sergio.belotti@nokia.com
Dhruv Dhody Huawei Technologies, Divyashree Technopark, Whitefield Bangalore, India
杜鲁夫·杜迪华为技术有限公司，印度班加罗尔怀特菲尔德Divyashree技术园
Email: dhruv.ietf@gmail.com
Email: dhruv.ietf@gmail.com
Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden
Daniele Ceccarelli Ericsson Torshamnsgatan，瑞典斯德哥尔摩48号
Email: daniele.ceccarelli@ericsson.com
Email: daniele.ceccarelli@ericsson.com
Bin Yeong Yoon ETRI
彬杨尹
Email: byyun@etri.re.kr
Email: byyun@etri.re.kr