Internet Engineering Task Force (IETF) D. King
Request for Comments: 7491 Old Dog Consulting
Category: Informational A. Farrel
ISSN: 2070-1721 Juniper Networks
March 2015
Internet Engineering Task Force (IETF) D. King
Request for Comments: 7491 Old Dog Consulting
Category: Informational A. Farrel
ISSN: 2070-1721 Juniper Networks
March 2015
A PCE-Based Architecture for Application-Based Network Operations
基于PCE的基于应用程序的网络操作体系结构
Abstract
摘要
Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.
内容分发、分布式数据库或数据中心间连接等服务对网络的运行提出了一系列新的要求。他们需要在各种网络应用（如点到点连接、网络虚拟化或移动回程）以及从分组（IP/MPLS）到光纤的一系列网络技术中按需和特定于应用程序的网络连接、可靠性和资源（如带宽）预留。为满足这些类型的需求而运行的环境称为基于应用程序的网络操作（ABNO）。ABNO汇集了许多现有技术，可能被视为使用了现有组件的工具箱，并通过一些新元素进行了增强。
This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.
本文档描述了ABNO的体系结构和框架，展示了这些组件是如何组合在一起的。它提供了现有技术的食谱，以满足体系结构和应用程序的需求。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7491.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7491.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Scope ......................................................5
2. Application-Based Network Operations (ABNO) .....................6
2.1. Assumptions ................................................6
2.2. Implementation of the Architecture .........................6
2.3. Generic ABNO Architecture ..................................7
2.3.1. ABNO Components .....................................8
2.3.2. Functional Interfaces ..............................15
3. ABNO Use Cases .................................................24
3.1. Inter-AS Connectivity .....................................24
3.2. Multi-Layer Networking ....................................30
3.2.1. Data Center Interconnection across
Multi-Layer Networks ...............................34
3.3. Make-before-Break .........................................37
3.3.1. Make-before-Break for Reoptimization ...............37
3.3.2. Make-before-Break for Restoration ..................38
3.3.3. Make-before-Break for Path Test and Selection ......40
3.4. Global Concurrent Optimization ............................42
3.4.1. Use Case: GCO with MPLS LSPs .......................43
3.5. Adaptive Network Management (ANM) .........................45
3.5.1. ANM Trigger ........................................46
3.5.2. Processing Request and GCO Computation .............46
3.5.3. Automated Provisioning Process .....................47
3.6. Pseudowire Operations and Management ......................48
3.6.1. Multi-Segment Pseudowires ..........................48
3.6.2. Path-Diverse Pseudowires ...........................50
3.6.3. Path-Diverse Multi-Segment Pseudowires .............51
3.6.4. Pseudowire Segment Protection ......................52
3.6.5. Applicability of ABNO to Pseudowires ...............52
3.7. Cross-Stratum Optimization (CSO) ..........................53
3.7.1. Data Center Network Operation ......................53
3.7.2. Application of the ABNO Architecture ...............56
3.8. ALTO Server ...............................................58
3.9. Other Potential Use Cases .................................61
3.9.1. Traffic Grooming and Regrooming ....................61
3.9.2. Bandwidth Scheduling ...............................62
4. Survivability and Redundancy within the ABNO Architecture ......62
5. Security Considerations ........................................63
6. Manageability Considerations ...................................63
7. Informative References .........................................64
Appendix A. Undefined Interfaces ..................................69
Acknowledgements ..................................................70
Contributors ......................................................71
Authors' Addresses ................................................71
1. Introduction ....................................................4
1.1. Scope ......................................................5
2. Application-Based Network Operations (ABNO) .....................6
2.1. Assumptions ................................................6
2.2. Implementation of the Architecture .........................6
2.3. Generic ABNO Architecture ..................................7
2.3.1. ABNO Components .....................................8
2.3.2. Functional Interfaces ..............................15
3. ABNO Use Cases .................................................24
3.1. Inter-AS Connectivity .....................................24
3.2. Multi-Layer Networking ....................................30
3.2.1. Data Center Interconnection across
Multi-Layer Networks ...............................34
3.3. Make-before-Break .........................................37
3.3.1. Make-before-Break for Reoptimization ...............37
3.3.2. Make-before-Break for Restoration ..................38
3.3.3. Make-before-Break for Path Test and Selection ......40
3.4. Global Concurrent Optimization ............................42
3.4.1. Use Case: GCO with MPLS LSPs .......................43
3.5. Adaptive Network Management (ANM) .........................45
3.5.1. ANM Trigger ........................................46
3.5.2. Processing Request and GCO Computation .............46
3.5.3. Automated Provisioning Process .....................47
3.6. Pseudowire Operations and Management ......................48
3.6.1. Multi-Segment Pseudowires ..........................48
3.6.2. Path-Diverse Pseudowires ...........................50
3.6.3. Path-Diverse Multi-Segment Pseudowires .............51
3.6.4. Pseudowire Segment Protection ......................52
3.6.5. Applicability of ABNO to Pseudowires ...............52
3.7. Cross-Stratum Optimization (CSO) ..........................53
3.7.1. Data Center Network Operation ......................53
3.7.2. Application of the ABNO Architecture ...............56
3.8. ALTO Server ...............................................58
3.9. Other Potential Use Cases .................................61
3.9.1. Traffic Grooming and Regrooming ....................61
3.9.2. Bandwidth Scheduling ...............................62
4. Survivability and Redundancy within the ABNO Architecture ......62
5. Security Considerations ........................................63
6. Manageability Considerations ...................................63
7. Informative References .........................................64
Appendix A. Undefined Interfaces ..................................69
Acknowledgements ..................................................70
Contributors ......................................................71
Authors' Addresses ................................................71
Networks today integrate multiple technologies allowing network infrastructure to deliver a variety of services to support the different characteristics and demands of applications. There is an increasing demand to make the network responsive to service requests issued directly from the application layer. This differs from the established model where services in the network are delivered in response to management commands driven by a human user.
今天的网络集成了多种技术，允许网络基础设施提供各种服务，以支持应用程序的不同特性和需求。越来越多的人要求网络响应直接从应用层发出的服务请求。这与已建立的模型不同，在该模型中，网络中的服务是响应由人类用户驱动的管理命令而交付的。
These application-driven requests and the services they establish place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet this type of application-aware requirement is said to have Application-Based Network Operations (ABNO).
这些应用程序驱动的请求及其建立的服务对网络的运行提出了一系列新的要求。他们需要在各种网络应用（如点到点连接、网络虚拟化或移动回程）以及从分组（IP/MPLS）到光纤的一系列网络技术中按需和特定于应用程序的网络连接、可靠性和资源（如带宽）预留。为满足这种类型的应用程序感知需求而运行的环境称为基于应用程序的网络操作（ABNO）。
The Path Computation Element (PCE) [RFC4655] was developed to provide path computation services for GMPLS- and MPLS-controlled networks. The applicability of PCEs can be extended to provide path computation and policy enforcement capabilities for ABNO platforms and services.
路径计算元件（PCE）[RFC4655]是为GMPLS和MPLS控制的网络提供路径计算服务而开发的。PCE的适用性可以扩展，为ABNO平台和服务提供路径计算和策略实施能力。
ABNO can provide the following types of service to applications by coordinating the components that operate and manage the network:
ABNO可以通过协调操作和管理网络的组件，为应用程序提供以下类型的服务：
- Optimization of traffic flows between applications to create an overlay network for communication in use cases such as file sharing, data caching or mirroring, media streaming, or real-time communications described as Application-Layer Traffic Optimization (ALTO) [RFC5693].
- 优化应用程序之间的通信流，以在文件共享、数据缓存或镜像、媒体流或实时通信（如应用层通信优化（ALTO））等用例中创建用于通信的覆盖网络[RFC5693]。
- Remote control of network components allowing coordinated programming of network resources through such techniques as Forwarding and Control Element Separation (ForCES) [RFC3746], OpenFlow [ONF], and the Interface to the Routing System (I2RS) [I2RS-Arch], or through the control plane coordinated through the PCE Communication Protocol (PCEP) [PCE-Init-LSP].
- 远程控制网络组件，允许通过转发和控制元素分离（ForCES）[RFC3746]、OpenFlow[ONF]和路由系统接口（I2RS）[I2RS Arch]等技术，或通过PCE通信协议（PCEP）协调的控制平面，对网络资源进行协调编程[PCE初始LSP]。
- Interconnection of Content Delivery Networks (CDNi) [RFC6707] through the establishment and resizing of connections between content distribution networks. Similarly, ABNO can coordinate inter-data center connections.
- 通过建立内容分发网络之间的连接并调整其大小，实现内容交付网络（CDNi）的互连[RFC6707]。同样，ABNO可以协调数据中心之间的连接。
- Network resource coordination to automate provisioning, and to facilitate traffic grooming and regrooming, bandwidth scheduling, and Global Concurrent Optimization using PCEP [RFC5557].
- 网络资源协调，以自动化资源调配，并使用PCEP促进流量疏导和重新规划、带宽调度和全局并发优化[RFC5557]。
- Virtual Private Network (VPN) planning in support of deployment of new VPN customers and to facilitate inter-data center connectivity.
- 虚拟专用网（VPN）规划，以支持新VPN客户的部署，并促进数据中心间的连接。
This document outlines the architecture and use cases for ABNO, and shows how the ABNO architecture can be used for coordinating control system and application requests to compute paths, enforce policies, and manage network resources for the benefit of the applications that use the network. The examination of the use cases shows the ABNO architecture as a toolkit comprising many existing components and protocols, and so this document looks like a cookbook. ABNO is compatible with pre-existing Network Management System (NMS) and Operations Support System (OSS) deployments as well as with more recent developments in programmatic networks such as Software-Defined Networking (SDN).
本文档概述了ABNO的体系结构和用例，并展示了ABNO体系结构如何用于协调控制系统和应用程序请求，以计算路径、实施策略和管理网络资源，从而使使用网络的应用程序受益。对用例的检查显示ABNO体系结构是一个包含许多现有组件和协议的工具包，因此本文档看起来像一本食谱。ABNO兼容现有的网络管理系统（NMS）和操作支持系统（OSS）部署，以及软件定义网络（SDN）等编程网络的最新发展。
This document describes a toolkit. It shows how existing functional components described in a large number of separate documents can be brought together within a single architecture to provide the function necessary for ABNO.
本文档描述了一个工具包。它展示了如何将大量单独文档中描述的现有功能组件整合到单个体系结构中，以提供ABNO所需的功能。
In many cases, existing protocols are known to be good enough or almost good enough to satisfy the requirements of interfaces between the components. In these cases, the protocols are called out as suitable candidates for use within an implementation of ABNO.
在许多情况下，已知现有协议足够好或几乎足够好以满足组件之间接口的要求。在这些情况下，这些协议被称为ABNO实现中使用的合适候选协议。
In other cases, it is clear that further work will be required, and in those cases a pointer to ongoing work that may be of use is provided. Where there is no current work that can be identified by the authors, a short description of the missing interface protocol is given in Appendix A.
在其他情况下，显然需要进一步的工作，在这些情况下，提供了一个指向正在进行的工作的指针，这些工作可能有用。如果作者无法确定当前的工作，则附录a中给出了缺失接口协议的简短描述。
Thus, this document may be seen as providing an applicability statement for existing protocols, and guidance for developers of new protocols or protocol extensions.
因此，本文件可被视为为为现有协议提供了适用性声明，并为新协议或协议扩展的开发人员提供了指导。
The principal assumption underlying this document is that existing technologies should be used where they are adequate for the task. Furthermore, when an existing technology is almost sufficient, it is assumed to be preferable to make minor extensions rather than to invent a whole new technology.
本文件的主要假设是，应在现有技术足以完成任务的情况下使用这些技术。此外，当现有技术几乎足够时，人们认为最好进行较小的扩展，而不是发明一种全新的技术。
Note that this document describes an architecture. Functional components are architectural concepts and have distinct and clear responsibilities. Pairs of functional components interact over functional interfaces that are, themselves, architectural concepts.
请注意，本文档描述了一种体系结构。功能组件是体系结构概念，具有明确的职责。成对的功能组件通过功能接口进行交互，这些接口本身就是体系结构概念。
It needs to be strongly emphasized that this document describes a functional architecture. It is not a software design. Thus, it is not intended that this architecture constrain implementations. However, the separation of the ABNO functions into separate functional components with clear interfaces between them enables implementations to choose which features to include and allows different functions to be distributed across distinct processes or even processors.
需要强调的是，本文档描述了一个功能架构。这不是一个软件设计。因此，该体系结构并不打算约束实现。然而，将ABNO功能分离为单独的功能组件，这些组件之间有明确的接口，这使得实现能够选择要包括哪些功能，并允许不同的功能分布在不同的进程甚至处理器上。
An implementation of this architecture may make several important decisions about the functional components:
该体系结构的实现可能会对功能组件做出若干重要决策：
- Multiple functional components may be grouped together into one software component such that all of the functions are bundled and only the external interfaces are exposed. This may have distinct advantages for fast paths within the software and can reduce interprocess communication overhead.
- 可以将多个功能组件组合到一个软件组件中，以便将所有功能捆绑在一起，并且仅公开外部接口。这对于软件内的快速路径可能具有明显的优势，并且可以减少进程间通信开销。
For example, an Active, Stateful PCE could be implemented as a single server combining the ABNO components of the PCE, the Traffic Engineering Database, the Label Switched Path Database, and the Provisioning Manager (see Section 2.3).
例如，一个活动的、有状态的PCE可以实现为一个单一的服务器，结合PCE的ABNO组件、流量工程数据库、标签交换路径数据库和供应管理器（参见第2.3节）。
- The functional components could be distributed across separate processes, processors, or servers so that the interfaces are exposed as external protocols.
- 功能组件可以分布在单独的进程、处理器或服务器上，以便接口作为外部协议公开。
For example, the Operations, Administration, and Maintenance (OAM) Handler (see Section 2.3.1.6) could be presented on a dedicated server in the network that consumes all status reports from the network, aggregates them, correlates them, and then dispatches notifications to other servers that need to understand what has happened.
例如，操作、管理和维护（OAM）处理程序（请参见第2.3.1.6节）可以显示在网络中的专用服务器上，该服务器使用来自网络的所有状态报告，聚合它们，关联它们，然后向需要了解发生了什么的其他服务器发送通知。
- There could be multiple instances of any or each of the components. That is, the function of a functional component could be partitioned across multiple software components with each responsible for handling a specific feature or a partition of the network.
- 任何组件或每个组件都可能有多个实例。也就是说，功能组件的功能可以跨多个软件组件进行分区，每个软件组件负责处理特定功能或网络分区。
For example, there may be multiple Traffic Engineering Databases (see Section 2.3.1.8) in an implementation, with each holding the topology information of a separate network domain (such as a network layer or an Autonomous System). Similarly, there could be multiple PCE instances, each processing a different Traffic Engineering Database, and potentially distributed on different servers under different management control. As a final example, there could be multiple ABNO Controllers, each with capability to support different classes of application or application service.
例如，在一个实现中可能有多个流量工程数据库（见第2.3.1.8节），每个数据库保存单独网络域（如网络层或自治系统）的拓扑信息。类似地，可能存在多个PCE实例，每个实例处理不同的流量工程数据库，并且可能分布在不同管理控制下的不同服务器上。最后一个例子是，可能有多个ABNO控制器，每个控制器都能够支持不同类别的应用程序或应用程序服务。
The purpose of the description of this architecture is to facilitate different implementations while offering interoperability between implementations of key components, and easy interaction with the applications and with the network devices.
该体系结构描述的目的是促进不同的实现，同时提供关键组件实现之间的互操作性，以及与应用程序和网络设备的轻松交互。
Figure 1 illustrates the ABNO architecture. The components and functional interfaces are discussed in Sections 2.3.1 and 2.3.2, respectively. The use cases described in Section 3 show how different components are used selectively to provide different services. It is important to understand that the relationships and interfaces shown between components in this figure are illustrative of some of the common or likely interactions; however, this figure does not preclude other interfaces and relationships as necessary to realize specific functionality.
图1说明了ABNO体系结构。组件和功能接口分别在第2.3.1节和第2.3.2节中讨论。第3节中描述的用例展示了如何有选择地使用不同的组件来提供不同的服务。重要的是要理解，图中显示的组件之间的关系和接口说明了一些常见或可能的交互；然而，该图并不排除实现特定功能所需的其他接口和关系。
+----------------------------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+-+---+---+----+-----------+---------------------------------+---+
| | | | | |
...|...|...|....|...........|.................................|......
: | | | | +----+----------------------+ | :
: | | | +--+---+ | | +---+---+ :
: | | | |Policy+--+ ABNO Controller +------+ | :
: | | | |Agent | | +--+ | OAM | :
: | | | +-+--+-+ +-+------------+----------+-+ | |Handler| :
: | | | | | | | | | | | :
: | | +-+---++ | +----+-+ +-------+-------+ | | +---+---+ :
: | | |ALTO | +-+ VNTM |--+ | | | | :
: | | |Server| +--+-+-+ | | | +--+---+ | :
: | | +--+---+ | | | PCE | | | I2RS | | :
: | | | +-------+ | | | | |Client| | :
: | | | | | | | | +-+--+-+ | :
: | +-+----+--+-+ | | | | | | | :
: | | Databases +-------:----+ | | | | | :
: | | TED | | +-+---+----+----+ | | | | :
: | | LSP-DB | | | | | | | | | :
: | +-----+--+--+ +-+---------------+-------+-+ | | | :
: | | | | Provisioning Manager | | | | :
: | | | +-----------------+---+-----+ | | | :
...|.......|..|.................|...|....|...|.......|..|.....|......
| | | | | | | | | |
| +-+--+-----------------+--------+-----------+----+ |
+----/ Client Network Layer \--+
| +----------------------------------------------------+ |
| | | | | |
++------+-------------------------+--------+----------+-----+-+
/ Server Network Layers \
+-----------------------------------------------------------------+
+----------------------------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+-+---+---+----+-----------+---------------------------------+---+
| | | | | |
...|...|...|....|...........|.................................|......
: | | | | +----+----------------------+ | :
: | | | +--+---+ | | +---+---+ :
: | | | |Policy+--+ ABNO Controller +------+ | :
: | | | |Agent | | +--+ | OAM | :
: | | | +-+--+-+ +-+------------+----------+-+ | |Handler| :
: | | | | | | | | | | | :
: | | +-+---++ | +----+-+ +-------+-------+ | | +---+---+ :
: | | |ALTO | +-+ VNTM |--+ | | | | :
: | | |Server| +--+-+-+ | | | +--+---+ | :
: | | +--+---+ | | | PCE | | | I2RS | | :
: | | | +-------+ | | | | |Client| | :
: | | | | | | | | +-+--+-+ | :
: | +-+----+--+-+ | | | | | | | :
: | | Databases +-------:----+ | | | | | :
: | | TED | | +-+---+----+----+ | | | | :
: | | LSP-DB | | | | | | | | | :
: | +-----+--+--+ +-+---------------+-------+-+ | | | :
: | | | | Provisioning Manager | | | | :
: | | | +-----------------+---+-----+ | | | :
...|.......|..|.................|...|....|...|.......|..|.....|......
| | | | | | | | | |
| +-+--+-----------------+--------+-----------+----+ |
+----/ Client Network Layer \--+
| +----------------------------------------------------+ |
| | | | | |
++------+-------------------------+--------+----------+-----+-+
/ Server Network Layers \
+-----------------------------------------------------------------+
Figure 1: Generic ABNO Architecture
图1：通用ABNO体系结构
This section describes the functional components shown as boxes in Figure 1. The interactions between those components, the functional interfaces, are described in Section 2.3.2.
本节描述了图1中方框所示的功能组件。第2.3.2节描述了这些组件（功能接口）之间的相互作用。
A Network Management System (NMS) or an Operations Support System (OSS) can be used to control, operate, and manage a network. Within the ABNO architecture, an NMS or OSS may issue high-level service requests to the ABNO Controller. It may also establish policies for the activities of the components within the architecture.
网络管理系统（NMS）或操作支持系统（OSS）可用于控制、操作和管理网络。在ABNO体系结构中，NMS或OSS可以向ABNO控制器发出高级服务请求。它还可以为体系结构中组件的活动建立策略。
The NMS and OSS can be consumers of network events reported through the OAM Handler and can act on these reports as well as displaying them to users and raising alarms. The NMS and OSS can also access the Traffic Engineering Database (TED) and Label Switched Path Database (LSP-DB) to show the users the current state of the network.
NMS和OSS可以是通过OAM处理程序报告的网络事件的使用者，可以对这些报告采取行动，并将其显示给用户并发出警报。NMS和OSS还可以访问流量工程数据库（TED）和标签交换路径数据库（LSP-DB），向用户显示网络的当前状态。
Lastly, the NMS and OSS may utilize a direct programmatic or configuration interface to interact with the network elements within the network.
最后，NMS和OSS可利用直接编程或配置接口与网络内的网元交互。
In addition to the NMS and OSS, services in the ABNO architecture may be requested by or on behalf of applications. In this context, the term "application" is very broad. An application may be a program that runs on a host or server and that provides services to a user, such as a video conferencing application. Alternatively, an application may be a software tool that a user uses to make requests to the network to set up specific services such as end-to-end connections or scheduled bandwidth reservations. Finally, an application may be a sophisticated control system that is responsible for arranging the provision of a more complex network service such as a virtual private network.
除NMS和OSS外，ABNO体系结构中的服务可能由应用程序或其代表请求。在这方面，“应用”一词非常广泛。应用程序可以是在主机或服务器上运行并向用户提供服务的程序，例如视频会议应用程序。或者，应用程序可以是用户用于向网络发出请求以建立特定服务（例如端到端连接或预定带宽预留）的软件工具。最后，应用程序可以是复杂的控制系统，负责安排提供更复杂的网络服务，例如虚拟专用网络。
For the sake of this architecture, all of these concepts of an application are grouped together and are shown as the Application Service Coordinator, since they are all in some way responsible for coordinating the activity of the network to provide services for use by applications. In practice, the function of the Application Service Coordinator may be distributed across multiple applications or servers.
出于这种体系结构的考虑，应用程序的所有这些概念都被分组在一起，并显示为应用程序服务协调器，因为它们都以某种方式负责协调网络活动，以提供应用程序使用的服务。实际上，应用程序服务协调器的功能可以分布在多个应用程序或服务器上。
The Application Service Coordinator communicates with the ABNO Controller to request operations on the network.
应用程序服务协调器与ABNO控制器通信，请求网络上的操作。
The ABNO Controller is the main gateway to the network for the NMS, OSS, and Application Service Coordinator for the provision of advanced network coordination and functions. The ABNO Controller governs the behavior of the network in response to changing network conditions and in accordance with application network requirements and policies. It is the point of attachment, and it invokes the right components in the right order.
ABNO控制器是NMS、OSS和应用服务协调器的主要网络网关，用于提供高级网络协调和功能。ABNO控制器控制网络行为，以响应不断变化的网络条件，并符合应用程序网络要求和策略。它是连接点，它以正确的顺序调用正确的组件。
The use cases in Section 3 provide a clearer picture of how the ABNO Controller interacts with the other components in the ABNO architecture.
第3节中的用例更清楚地描述了ABNO控制器如何与ABNO体系结构中的其他组件交互。
Policy plays a very important role in the control and management of the network. It is, therefore, significant in influencing how the key components of the ABNO architecture operate.
策略在网络的控制和管理中起着非常重要的作用。因此，这对于影响ABNO体系结构的关键组件的运行方式具有重要意义。
Figure 1 shows the Policy Agent as a component that is configured by the NMS/OSS with the policies that it applies. The Policy Agent is responsible for propagating those policies into the other components of the system.
图1将策略代理显示为NMS/OSS使用其应用的策略配置的组件。策略代理负责将这些策略传播到系统的其他组件中。
Simplicity in the figure necessitates leaving out many of the policy interactions that will take place. Although the Policy Agent is only shown interacting with the ABNO Controller, the ALTO Server, and the Virtual Network Topology Manager (VNTM), it will also interact with a number of other components and the network elements themselves. For example, the Path Computation Element (PCE) will be a Policy Enforcement Point (PEP) [RFC2753] as described in [RFC5394], and the Interface to the Routing System (I2RS) Client will also be a PEP as noted in [I2RS-Arch].
图中的简单性要求省略将要发生的许多策略交互。尽管策略代理仅显示为与ABNO控制器、ALTO服务器和虚拟网络拓扑管理器（VNTM）交互，但它也将与许多其他组件和网络元素本身交互。例如，路径计算元素（PCE）将是[RFC5394]中所述的策略实施点（PEP）[RFC2753]，与路由系统（I2RS）客户端的接口也将是[I2RS Arch]中所述的PEP。
The Interface to the Routing System (I2RS) is described in [I2RS-Arch]. The interface provides a programmatic way to access (for read and write) the routing state and policy information on routers in the network.
[I2RS Arch]中描述了与路由系统（I2RS）的接口。该接口提供了一种编程方式来访问（用于读写）网络中路由器的路由状态和策略信息。
The I2RS Client is introduced in [I2RS-PS]. Its purpose is to manage information requests across a number of routers (each of which runs an I2RS Agent) and coordinate setting or gathering state to/from those routers.
[I2RS-PS]中介绍了I2RS客户端。它的目的是跨多个路由器（每个路由器运行I2RS代理）管理信息请求，并协调设置或收集这些路由器的状态。
Operations, Administration, and Maintenance (OAM) plays a critical role in understanding how a network is operating, detecting faults, and taking the necessary action to react to problems in the network.
操作、管理和维护（OAM）在了解网络如何运行、检测故障以及采取必要措施应对网络问题方面起着关键作用。
Within the ABNO architecture, the OAM Handler is responsible for receiving notifications (often called alerts) from the network about potential problems, for correlating them, and for triggering other components of the system to take action to preserve or recover the services that were established by the ABNO Controller. The OAM Handler also reports network problems and, in particular, service-affecting problems to the NMS, OSS, and Application Service Coordinator.
在ABNO体系结构中，OAM处理程序负责接收来自网络的关于潜在问题的通知（通常称为警报），将它们关联起来，并触发系统的其他组件采取措施以保留或恢复ABNO控制器建立的服务。OAM处理程序还向NMS、OSS和应用程序服务协调员报告网络问题，特别是影响服务的问题。
Additionally, the OAM Handler interacts with the devices in the network to initiate OAM actions within the data plane, such as monitoring and testing.
此外，OAM处理程序与网络中的设备交互，以在数据平面内启动OAM操作，例如监视和测试。
PCE is introduced in [RFC4655]. It is a functional component that services requests to compute paths across a network graph. In particular, it can generate traffic-engineered routes for MPLS-TE and GMPLS Label Switched Paths (LSPs). The PCE may receive these requests from the ABNO Controller, from the Virtual Network Topology Manager, or from network elements themselves.
[RFC4655]中引入了PCE。它是一个功能组件，为计算网络图中路径的请求提供服务。特别是，它可以为MPLS-TE和GMPLS标签交换路径（LSP）生成流量工程路由。PCE可以从ABNO控制器、虚拟网络拓扑管理器或网络元件本身接收这些请求。
The PCE operates on a view of the network topology stored in the Traffic Engineering Database (TED). A more sophisticated computation may be provided by a Stateful PCE that enhances the TED with a database (the LSP-DB -- see Section 2.3.1.8.2) containing information about the LSPs that are provisioned and operational within the network as described in [RFC4655] and [Stateful-PCE].
PCE在交通工程数据库（TED）中存储的网络拓扑视图上运行。有状态PCE可以提供更复杂的计算，该PCE使用数据库（LSP-DB——见第2.3.1.8.2节）增强TED，该数据库包含[RFC4655]和[Stateful PCE]中所述的关于网络内供应和运行的LSP的信息。
Additional functionality in an Active PCE allows a functional component that includes a Stateful PCE to make provisioning requests to set up new services or to modify in-place services as described in [Stateful-PCE] and [PCE-Init-LSP]. This function may directly access the network elements or may be channeled through the Provisioning Manager.
活动PCE中的附加功能允许包括有状态PCE的功能组件发出设置请求以设置新服务或修改就地服务，如[Stateful PCE]和[PCE Init LSP]中所述。此功能可以直接访问网络元素，也可以通过资源调配管理器进行引导。
Coordination between multiple PCEs operating on different TEDs can prove useful for performing path computation in multi-domain or multi-layer networks. A domain in this case might be an Autonomous System (AS), thus enabling inter-AS path computation.
在不同TED上运行的多个PCE之间的协调对于在多域或多层网络中执行路径计算非常有用。在这种情况下，域可能是自治系统（AS），因此支持AS间路径计算。
Since the PCE is a key component of the ABNO architecture, a better view of its role can be gained by examining the use cases described in Section 3.
由于PCE是ABNO体系结构的一个关键组件，通过检查第3节中描述的用例，可以更好地了解其作用。
The ABNO architecture includes a number of databases that contain information stored for use by the system. The two main databases are the TED and the LSP Database (LSP-DB), but there may be a number of other databases used to contain information about topology (ALTO Server), policy (Policy Agent), services (ABNO Controller), etc.
ABNO体系结构包括许多数据库，其中包含存储供系统使用的信息。两个主要数据库是TED和LSP数据库（LSP-DB），但可能有许多其他数据库用于包含有关拓扑（ALTO服务器）、策略（策略代理）、服务（ABNO控制器）等的信息。
In the text that follows, specific key components that are consumers of the databases are highlighted. It should be noted that the databases are available for inspection by any of the ABNO components. Updates to the databases should be handled with some care, since allowing multiple components to write to a database can be the cause of a number of contention and sequencing problems.
在下面的文本中，将突出显示作为数据库使用者的特定关键组件。应注意的是，数据库可供ABNO的任何组件检查。对数据库的更新应谨慎处理，因为允许多个组件写入数据库可能会导致许多争用和排序问题。
The TED is a data store of topology information about a network that may be enhanced with capability data (such as metrics or bandwidth capacity) and active status information (such as up/down status or residual unreserved bandwidth).
TED是关于网络的拓扑信息的数据存储，可以使用能力数据（例如度量或带宽容量）和活动状态信息（例如向上/向下状态或剩余未保留带宽）来增强。
The TED may be built from information supplied by the network or from data (such as inventory details) sourced through the NMS/OSS.
TED可以根据网络提供的信息或通过NMS/OSS获取的数据（如库存详细信息）构建。
The principal use of the TED in the ABNO architecture is to provide the raw data on which the Path Computation Element operates. But the TED may also be inspected by users at the NMS/OSS to view the current status of the network and may provide information to application services such as Application-Layer Traffic Optimization (ALTO) [RFC5693].
ABNO体系结构中TED的主要用途是提供路径计算元素操作的原始数据。但是，NMS/OSS上的用户也可以检查TED，以查看网络的当前状态，并可以向应用程序服务提供信息，例如应用层流量优化（ALTO）[RFC5693]。
The LSP-DB is a data store of information about LSPs that have been set up in the network or that could be established. The information stored includes the paths and resource usage of the LSPs.
LSP-DB是关于已在网络中建立或可建立的LSP的信息的数据存储。存储的信息包括LSP的路径和资源使用情况。
The LSP-DB may be built from information generated locally. For example, when LSPs are provisioned, the LSP-DB can be updated. The database can also be constructed from information gathered from the network by polling or reading the state of LSPs that have already been set up.
LSP-DB可以根据本地生成的信息构建。例如，当供应LSP时，可以更新LSP-DB。还可以通过轮询或读取已设置的LSP的状态，从网络收集信息来构建数据库。
The main use of the LSP-DB within the ABNO architecture is to enhance the planning and optimization of LSPs. New LSPs can be established to be path-disjoint from other LSPs in order to offer protected services; LSPs can be rerouted in order to put them on more optimal paths or to make network resources available for other LSPs; LSPs can be rapidly repaired when a network failure is reported; LSPs can be moved onto other paths in order to avoid resources that have planned maintenance outages. A Stateful PCE (see Section 2.3.1.7) is a primary consumer of the LSP-DB.
ABNO体系结构中LSP-DB的主要用途是加强LSP的规划和优化。为了提供受保护的服务，可以建立与其他LSP路径不相交的新LSP；LSP可以重新路由，以便将其置于更优化的路径上，或使网络资源可用于其他LSP；当报告网络故障时，LSP可以快速修复；LSP可以移动到其他路径上，以避免出现计划维护中断的资源。有状态PCE（见第2.3.1.7节）是LSP-DB的主要用户。
The TED may, itself, be supplemented by SRLG information that assigns to each network resource one or more identifiers that associate the resource with other resources in the same TED that share the same risk of failure.
TED本身可以由SRLG信息来补充，SRLG信息向每个网络资源分配一个或多个标识符，该标识符将资源与同一TED中共享相同故障风险的其他资源相关联。
While this information can be highly useful, it may be supplemented by additional detailed information maintained in a separate database and indexed using the SRLG identifier from the TED. Such a database can interpret SRLG information provided by other networks (such as server networks), can provide failure probabilities associated with each SRLG, can offer prioritization when SRLG-disjoint paths cannot be found, and can correlate SRLGs between different server networks or between different peer networks.
虽然这些信息可能非常有用，但可以通过单独数据库中维护的附加详细信息进行补充，并使用TED的SRLG标识符编制索引。这样的数据库可以解释由其他网络（例如服务器网络）提供的SRLG信息，可以提供与每个SRLG相关联的故障概率，可以在无法找到SRLG不相交路径时提供优先级，并且可以将不同服务器网络之间或不同对等网络之间的SRLG关联起来。
There may be other databases that are built within the ABNO system and that are referenced when operating the network. These databases might include information about, for example, traffic flows and demands, predicted or scheduled traffic demands, link and node failure and repair history, network resources such as packet labels and physical labels (i.e., MPLS and GMPLS labels), etc.
ABNO系统内可能还有其他数据库，在操作网络时会引用这些数据库。这些数据库可能包括关于例如业务流和需求、预测或调度的业务需求、链路和节点故障和修复历史、网络资源（例如分组标签和物理标签（即MPLS和GMPLS标签））等的信息。
As mentioned in Section 2.3.1.8.1, the TED may be enhanced by inventory information. It is quite likely in many networks that such an inventory is held in a separate database (the Inventory Database) that includes details of the manufacturer, model, installation date, etc.
如第2.3.1.8.1节所述，可通过库存信息增强TED。在许多网络中，此类库存很可能保存在单独的数据库（库存数据库）中，其中包括制造商、型号、安装日期等的详细信息。
The ALTO Server provides network information to the application layer based on abstract maps of a network region. This information provides a simplified view, but it is useful to steer application-layer traffic. ALTO services enable service providers to share information about network locations and the costs of paths between
ALTO服务器根据网络区域的抽象地图向应用层提供网络信息。此信息提供了一个简化的视图，但对于控制应用程序层流量非常有用。ALTO服务使服务提供商能够共享有关网络位置和路径成本的信息
them. The selection criteria to choose between two locations may depend on information such as maximum bandwidth, minimum cross-domain traffic, lower cost to the user, etc.
他们在两个位置之间选择的选择标准可能取决于诸如最大带宽、最小跨域通信量、用户的较低成本等信息。
The ALTO Server generates ALTO views to share information with the Application Service Coordinator so that it can better select paths in the network to carry application-layer traffic. The ALTO views are computed based on information from the network databases, from policies configured by the Policy Agent, and through the algorithms used by the PCE.
ALTO服务器生成ALTO视图，与应用程序服务协调器共享信息，以便更好地选择网络中的路径以承载应用程序层流量。ALTO视图是根据来自网络数据库、策略代理配置的策略以及PCE使用的算法的信息计算的。
Specifically, the base ALTO protocol [RFC7285] defines a single-node abstract view of a network to the Application Service Coordinator. Such a view consists of two maps: a network map and a cost map. A network map defines multiple Provider-defined Identifiers (PIDs), which represent entrance points to the network. Each node in the application layer is known as an End Point (EP), and each EP is assigned to a PID, because PIDs are the entry points of the application in the network. As defined in [RFC7285], a PID can denote a subnet, a set of subnets, a metropolitan area, a Point of Presence (PoP), etc. Each such network region can be a single domain or multiple networks; it is just the view that the ALTO Server is exposing to the application layer. A cost map provides costs between EPs and/or PIDs. The criteria that the Application Service Coordinator uses to choose application routes between two locations may depend on attributes such as maximum bandwidth, minimum cross-domain traffic, lower cost to the user, etc.
具体而言，基本ALTO协议[RFC7285]向应用程序服务协调器定义了网络的单节点抽象视图。这种视图由两个图组成：网络图和成本图。网络映射定义了多个提供者定义的标识符（PID），它们表示网络的入口点。应用层中的每个节点称为端点（EP），每个EP被分配给一个PID，因为PID是网络中应用程序的入口点。如[RFC7285]中所定义，PID可以表示子网、一组子网、城域、存在点（PoP）等。每个这样的网络区域可以是单个域或多个网络；这只是ALTO服务器向应用程序层公开的视图。成本图提供EPs和/或PID之间的成本。应用程序服务协调器用于在两个位置之间选择应用程序路由的标准可能取决于诸如最大带宽、最小跨域流量、用户较低成本等属性。
A Virtual Network Topology (VNT) is defined in [RFC5212] as a set of one or more LSPs in one or more lower-layer networks that provides information for efficient path handling in an upper-layer network. For instance, a set of LSPs in a wavelength division multiplexed (WDM) network can provide connectivity as virtual links in a higher-layer packet-switched network.
[RFC5212]将虚拟网络拓扑（VNT）定义为一个或多个下层网络中的一个或多个LSP的集合，该LSP为上层网络中的有效路径处理提供信息。例如，波分多路复用（WDM）网络中的一组LSP可以作为更高层分组交换网络中的虚拟链路提供连接。
The VNT enhances the physical/dedicated links that are available in the upper-layer network and is configured by setting up or tearing down the lower-layer LSPs and by advertising the changes into the higher-layer network. The VNT can be adapted to traffic demands so that capacity in the higher-layer network can be created or released as needed. Releasing unwanted VNT resources makes them available in the lower-layer network for other uses.
VNT增强了上层网络中可用的物理/专用链路，并通过设置或拆除下层LSP以及向上层网络公布更改来进行配置。VNT可以适应业务需求，以便可以根据需要创建或释放更高层网络中的容量。释放不需要的VNT资源可以使它们在底层网络中用于其他用途。
The creation of virtual topology for inclusion in a network is not a simple task. Decisions must be made about which nodes in the upper layer it is best to connect, in which lower-layer network to provision LSPs to provide the connectivity, and how to route the LSPs in the lower-layer network. Furthermore, some specific actions have to be taken to cause the lower-layer LSPs to be provisioned and the connectivity in the upper-layer network to be advertised.
创建虚拟拓扑以包含在网络中并不是一项简单的任务。必须决定上层中哪些节点最好连接，在哪个下层网络中提供LSP以提供连接，以及如何在下层网络中路由LSP。此外，必须采取一些特定动作，以使得供应下层lsp并且通告上层网络中的连接性。
[RFC5623] describes how the VNTM may instantiate connections in the server layer in support of connectivity in the client layer. Within the ABNO architecture, the creation of new connections may be delegated to the Provisioning Manager as discussed in Section 2.3.1.11.
[RFC5623]描述了VNTM如何实例化服务器层中的连接，以支持客户端层中的连接。在ABNO体系结构中，新连接的创建可委托给供应管理器，如第2.3.1.11节所述。
All of these actions and decisions are heavily influenced by policy, so the VNTM component that coordinates them takes input from the Policy Agent. The VNTM is also closely associated with the PCE for the upper-layer network and each of the PCEs for the lower-layer networks.
所有这些操作和决策都受到策略的严重影响，因此协调它们的VNTM组件从策略代理获取输入。VNTM还与上层网络的PCE和下层网络的每个PCE密切相关。
The Provisioning Manager is responsible for making or channeling requests for the establishment of LSPs. This may be instructions to the control plane running in the networks or may involve the programming of individual network devices. In the latter case, the Provisioning Manager may act as an OpenFlow Controller [ONF].
供应管理器负责提出或引导建立LSP的请求。这可能是对在网络中运行的控制平面的指令，或者可能涉及对单个网络设备的编程。在后一种情况下，供应管理器可以充当OpenFlow控制器[ONF]。
See Section 2.3.2.6 for more details of the interactions between the Provisioning Manager and the network.
有关Provisioning Manager与网络之间交互的更多详细信息，请参见第2.3.2.6节。
The client and server networks are shown in Figure 1 as illustrative examples of the fact that the ABNO architecture may be used to coordinate services across multiple networks where lower-layer networks provide connectivity in upper-layer networks.
客户机和服务器网络如图1所示，作为ABNO体系结构可用于跨多个网络协调服务的示例，其中较低层网络提供上层网络中的连接。
Section 3.2 describes a set of use cases for multi-layer networking.
第3.2节描述了多层网络的一组用例。
This section describes the interfaces between functional components that might be externalized in an implementation allowing the components to be distributed across platforms. Where existing protocols might provide all or most of the necessary capabilities, they are noted. Appendix A notes the interfaces where more protocol specification may be needed.
本节描述功能组件之间的接口，这些功能组件可能在实现中外部化，从而允许组件跨平台分布。当现有协议可能提供所有或大部分必要功能时，应注意这些协议。附录A说明了可能需要更多协议规范的接口。
As noted at the top of Section 2.3, it is important to understand that the relationships and interfaces shown between components in Figure 1 are illustrative of some of the common or likely interactions; however, this figure and the descriptions in the subsections below do not preclude other interfaces and relationships as necessary to realize specific functionality. Thus, some of the interfaces described below might not be visible as specific relationships in Figure 1, but they can nevertheless exist.
如第2.3节顶部所述，重要的是要理解图1中所示组件之间的关系和接口说明了一些常见或可能的交互；但是，此图和以下小节中的描述并不排除实现特定功能所需的其他接口和关系。因此，下面描述的一些接口可能无法作为图1中的特定关系显示，但它们仍然可以存在。
The network devices may be configured or programmed directly from the NMS/OSS. Many protocols already exist to perform these functions, including the following:
网络设备可以直接从NMS/OSS进行配置或编程。已经存在许多协议来执行这些功能，包括：
- SNMP [RFC3412]
- SNMP[RFC3412]
- The Network Configuration Protocol (NETCONF) [RFC6241]
- 网络配置协议（NETCONF）[RFC6241]
- RESTCONF [RESTCONF]
- RESTCONF[RESTCONF]
- The General Switch Management Protocol (GSMP) [RFC3292]
- 通用交换机管理协议（GSMP）[RFC3292]
- ForCES [RFC5810]
- 部队[RFC5810]
- OpenFlow [ONF]
- OpenFlow[ONF]
- PCEP [PCE-Init-LSP]
- PCEP[PCE初始LSP]
The TeleManagement Forum (TMF) Multi-Technology Operations Systems Interface (MTOSI) standard [TMF-MTOSI] was developed to facilitate application-to-application interworking and provides network-level management capabilities to discover, configure, and activate resources. Initially, the MTOSI information model was only capable of representing connection-oriented networks and resources. In later releases, support was added for connectionless networks. MTOSI is, from the NMS perspective, a north-bound interface and is based on SOAP web services.
远程管理论坛（TMF）多技术操作系统接口（MTOSI）标准[TMF-MTOSI]的开发旨在促进应用程序对应用程序的互通，并提供网络级管理能力，以发现、配置和激活资源。最初，MTOSI信息模型只能表示面向连接的网络和资源。在以后的版本中，添加了对无连接网络的支持。从NMS的角度来看，MTOSI是一个北向接口，基于SOAP web服务。
From the ABNO perspective, network configuration is a pass-through function. It can be seen represented on the left-hand side of Figure 1.
从ABNO的角度来看，网络配置是一种传递功能。它可以在图1的左侧看到。
As described in Section 2.3.1.8, the TED provides details of the capabilities and state of the network for use by the ABNO system and the PCE in particular.
如第2.3.1.8节所述，TED提供了ABNO系统特别是PCE使用的网络能力和状态的详细信息。
The TED can be constructed by participating in the IGP-TE protocols run by the networks (for example, OSPF-TE [RFC3630] and IS-IS TE [RFC5305]). Alternatively, the TED may be fed using link-state distribution extensions to BGP [BGP-LS].
TED可以通过参与网络运行的IGP-TE协议（例如，OSPF-TE[RFC3630]和IS-IS TE[RFC5305]）来构建。或者，可以使用到BGP[BGP-LS]的链路状态分布扩展来馈送TED。
The ABNO system may maintain a single TED unified across multiple networks or may retain a separate TED for each network.
ABNO系统可以在多个网络中维护一个统一的TED，也可以为每个网络保留一个单独的TED。
Additionally, an ALTO Server [RFC5693] may provide an abstracted topology from a network to build an application-level TED that can be used by a PCE to compute paths between servers and application-layer entities for the provision of application services.
此外，ALTO服务器[RFC5693]可提供来自网络的抽象拓扑以构建应用级TED，该应用级TED可由PCE用于计算服务器与应用层实体之间用于提供应用服务的路径。
The TED may be enhanced by inventory information supplied from the NMS/OSS. This may supplement the data collected as described in Section 2.3.2.2 with information that is not normally distributed within the network, such as node types and capabilities, or the characteristics of optical links.
可通过NMS/OSS提供的库存信息增强TED。这可以用网络中非正态分布的信息补充第2.3.2.2节所述收集的数据，如节点类型和能力，或光链路的特性。
No protocol is currently identified for this interface, but the protocol developed or adopted to satisfy the requirements of the Interface to the Routing System (I2RS) [I2RS-Arch] may be a suitable candidate because it is required to be able to distribute bulk routing state information in a well-defined encoding language. Another candidate protocol may be NETCONF [RFC6241] passing data encoded using YANG [RFC6020].
目前尚未确定该接口的协议，但为满足路由系统（I2RS）[I2RS Arch]接口的要求而开发或采用的协议可能是合适的候选协议，因为它需要能够以定义良好的编码语言分发批量路由状态信息。另一个候选协议可以是NETCONF[RFC6241]传递使用YANG[rfc602]编码的数据。
Note that, in general, any combination of protocol and encoding that is suitable for presenting the TED as described in Section 2.3.2.4 will likely be suitable (or could be made suitable) for enabling write-access to the TED as described in this section.
请注意，一般而言，适用于呈现第2.3.2.4节所述TED的协议和编码的任何组合都可能适用于（或可能适用于）启用本节所述TED的写访问。
The TED may be presented north-bound from the ABNO system for use by an NMS/OSS or by the Application Service Coordinator. This allows users and applications to get a view of the network topology and the status of the network resources. It also allows planning and provisioning of application services.
TED可以从ABNO系统显示为北行，供NMS/OSS或应用服务协调员使用。这允许用户和应用程序查看网络拓扑和网络资源的状态。它还允许规划和提供应用程序服务。
There are several protocols available for exporting the TED north-bound:
有几种协议可用于导出TED北向：
- The ALTO protocol [RFC7285] is designed to distribute the abstracted topology used by an ALTO Server and may prove useful for exporting the TED. The ALTO Server provides the cost between EPs
- ALTO协议[RFC7285]设计用于分发ALTO服务器使用的抽象拓扑，并且可能被证明对导出TED有用。ALTO服务器提供EPs之间的成本
or between PIDs, so the application layer can select which is the most appropriate connection for the information exchange between its application end points.
或者在PID之间，因此应用程序层可以选择最适合在其应用程序端点之间进行信息交换的连接。
- The same protocol used to export topology information from the network can be used to export the topology from the TED [BGP-LS].
- 用于从网络导出拓扑信息的协议也可用于从TED[BGP-LS]导出拓扑。
- The I2RS [I2RS-Arch] will require a protocol that is capable of handling bulk routing information exchanges that would be suitable for exporting the TED. In this case, it would make sense to have a standardized representation of the TED in a formal data modeling language such as YANG [RFC6020] so that an existing protocol such as NETCONF [RFC6241] or the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] could be used.
- I2RS[I2RS Arch]需要一个能够处理批量路由信息交换的协议，该协议适合导出TED。在这种情况下，用正式的数据建模语言（如YANG[RFC6020]）对TED进行标准化表示是有意义的，这样就可以使用现有的协议，如NETCONF[RFC6241]或可扩展消息和状态协议（XMPP）[RFC6120]。
Note that export from the TED can be a full dump of the content (expressed in a suitable abstraction language) as described above, or it could be an aggregated or filtered set of data based on policies or specific requirements. Thus, the relationships shown in Figure 1 may be a little simplistic in that the ABNO Controller may also be involved in preparing and presenting the TED information over a north-bound interface.
请注意，TED的导出可以是如上所述的内容的完整转储（以适当的抽象语言表示），也可以是基于策略或特定需求的聚合或过滤数据集。因此，图1所示的关系可能有点简单化，因为ABNO控制器也可能参与准备和呈现北向接口上的TED信息。
As originally specified in the PCE architecture [RFC4655], network elements can make path computation requests to a PCE using PCEP [RFC5440]. This facilitates the network setting up LSPs in response to simple connectivity requests, and it allows the network to reoptimize or repair LSPs.
正如PCE体系结构[RFC4655]中最初规定的那样，网元可以使用PCEP[RFC5440]向PCE发出路径计算请求。这有助于网络根据简单的连接请求设置LSP，并允许网络重新优化或修复LSP。
As described in Section 2.3.1.11, the Provisioning Manager makes or channels requests to provision resources in the network. These operations can take place at two levels: there can be requests to program/configure specific resources in the data or forwarding planes, and there can be requests to trigger a set of actions to be programmed with the assistance of a control plane.
如第2.3.1.11节所述，供应管理器发出或发送请求，以在网络中供应资源。这些操作可以在两个级别上进行：可以请求对数据或转发平面中的特定资源进行编程/配置，也可以请求触发在控制平面协助下编程的一组操作。
A number of protocols already exist to provision network resources, as follows:
已经存在许多协议来提供网络资源，如下所示：
o Program/configure specific network resources
o 编程/配置特定网络资源
- ForCES [RFC5810] defines a protocol for separation of the control element (the Provisioning Manager) from the forwarding elements in each node in the network.
- ForCES[RFC5810]定义了一个协议，用于将网络中每个节点中的控制元素（供应管理器）与转发元素分离。
- The General Switch Management Protocol (GSMP) [RFC3292] is an asymmetric protocol that allows one or more external switch controllers (such as the Provisioning Manager) to establish and maintain the state of a label switch such as an MPLS switch.
- 通用交换机管理协议（GSMP）[RFC3292]是一种非对称协议，允许一个或多个外部交换机控制器（如供应管理器）建立和维护标签交换机（如MPLS交换机）的状态。
- OpenFlow [ONF] is a communications protocol that gives an OpenFlow Controller (such as the Provisioning Manager) access to the forwarding plane of a network switch or router in the network.
- OpenFlow[ONF]是一种通信协议，它允许OpenFlow控制器（如供应管理器）访问网络中网络交换机或路由器的转发平面。
- Historically, other configuration-based mechanisms have been used to set up the forwarding/switching state at individual nodes within networks. Such mechanisms have ranged from non-standard command line interfaces (CLIs) to various standards-based options such as Transaction Language 1 (TL1) [TL1] and SNMP [RFC3412]. These mechanisms are not designed for rapid operation of a network and are not easily programmatic. They are not proposed for use by the Provisioning Manager as part of the ABNO architecture.
- 历史上，其他基于配置的机制已用于在网络中的各个节点上设置转发/交换状态。这些机制包括非标准命令行接口（CLI）和各种基于标准的选项，如事务语言1（TL1）[TL1]和SNMP[RFC3412]。这些机制不是为网络的快速运行而设计的，也不容易编程。它们不建议由资源调配管理器作为ABNO体系结构的一部分使用。
- NETCONF [RFC6241] provides a more active configuration protocol that may be suitable for bulk programming of network resources. Its use in this way is dependent on suitable YANG modules being defined for the necessary options. Early work in the IETF's NETMOD working group is focused on a higher level of routing function more comparable with the function discussed in Section 2.3.2.8; see [YANG-Rtg].
- NETCONF[RFC6241]提供了一种更活跃的配置协议，该协议可能适用于网络资源的批量编程。这种方式的使用取决于为必要选项定义的合适模块。IETF的NETMOD工作组的早期工作重点是更高级别的路由功能，与第2.3.2.8节中讨论的功能更具可比性；见[YANG Rtg]。
- The [TMF-MTOSI] specification provides provisioning, activation, deactivation, and release of resources via the Service Activation Interface (SAI). The Common Communication Vehicle (CCV) is the middleware required to implement MTOSI. The CCV is then used to provide middleware abstraction in combination with the Web Services Description Language (WSDL) to allow MTOSIs to be bound to different middleware technologies as needed.
- [TMF-MTOSI]规范通过服务激活接口（SAI）提供资源的供应、激活、停用和释放。公共通信工具（CCV）是实现MTOSI所需的中间件。然后使用CCV结合Web服务描述语言（WSDL）提供中间件抽象，以允许MTOS根据需要绑定到不同的中间件技术。
o Trigger actions through the control plane
o 通过控制平面触发动作
- LSPs can be requested using a management system interface to the head end of the LSP using tools such as CLIs, TL1 [TL1], or SNMP [RFC3412]. Configuration at this granularity is not as time-critical as when individual network resources are programmed, because the main task of programming end-to-end connectivity is devolved to the control plane. Nevertheless, these mechanisms remain unsuitable for programmatic control of the network and are not proposed for use by the Provisioning Manager as part of the ABNO architecture.
- 可以使用诸如CLIs、TL1[TL1]或SNMP[RFC3412]之类的工具，使用到LSP前端的管理系统接口请求LSP。这种粒度下的配置不像对单个网络资源进行编程时那样具有时间关键性，因为编程端到端连接的主要任务被转移到控制平面。然而，这些机制仍然不适用于网络的编程控制，并且不建议由供应管理器作为ABNO体系结构的一部分使用。
- As noted above, NETCONF [RFC6241] provides a more active configuration protocol. This may be particularly suitable for requesting the establishment of LSPs. Work would be needed to complete a suitable YANG module.
- 如上所述，NETCONF[RFC6241]提供了一个更活跃的配置协议。这可能特别适合于请求建立lsp。需要完成一个合适的模块。
- The PCE Communication Protocol (PCEP) [RFC5440] has been proposed as a suitable protocol for requesting the establishment of LSPs [PCE-Init-LSP]. This works well, because the protocol elements necessary are exactly the same as those used to respond to a path computation request.
- PCE通信协议（PCEP）[RFC5440]已被提议为请求建立LSP[PCE Init LSP]的合适协议。这很好，因为所需的协议元素与用于响应路径计算请求的协议元素完全相同。
The functional element that issues PCEP requests to establish LSPs is known as an "Active PCE"; however, it should be noted that the ABNO functional component responsible for requesting LSPs is the Provisioning Manager. Other controllers like the VNTM and the ABNO Controller use the services of the Provisioning Manager to isolate the twin functions of computing and requesting paths from the provisioning mechanisms in place with any given network.
发出PCEP请求以建立LSP的功能元件称为“活动PCE”；但是，应该注意，负责请求LSP的ABNO功能组件是Provisioning Manager。其他控制器（如VNTM和ABNO控制器）使用Provisioning Manager的服务将计算和请求路径这两项功能与任何给定网络中的配置机制隔离开来。
Note that I2RS does not provide a mechanism for control of network resources at this level, as it is designed to provide control of routing state in routers, not forwarding state in the data plane.
请注意，I2RS不提供此级别的网络资源控制机制，因为它旨在提供路由器中路由状态的控制，而不是数据平面中的转发状态。
Once resources have been provisioned or connections established in the network, it is important that the ABNO system can determine the state of the network. Similarly, when provisioned resources are modified or taken out of service, the changes in the network need to be understood by the ABNO system. This function falls into four categories:
一旦在网络中配置了资源或建立了连接，ABNO系统就必须能够确定网络的状态。类似地，当所提供的资源被修改或停止服务时，ABNO系统需要了解网络中的变化。此功能分为四类：
- Updates to the TED are gathered as described in Section 2.3.2.2.
- 如第2.3.2.2节所述，收集TED的更新。
- Explicit notification of the successful establishment and the subsequent state of the LSP can be provided through extensions to PCEP as described in [Stateful-PCE] and [PCE-Init-LSP].
- 如[Stateful PCE]和[PCE Init LSP]中所述，可以通过对PCEP的扩展来提供LSP成功建立和后续状态的明确通知。
- OAM can be commissioned and the results inspected by the OAM Handler as described in Section 2.3.2.14.
- OAM可以按照第2.3.2.14节的说明进行调试，并由OAM处理程序检查结果。
- A number of ABNO components may make inquiries and inspect network state through a variety of techniques, including I2RS, NETCONF, or SNMP.
- 许多ABNO组件可以通过各种技术进行查询和检查网络状态，包括I2RS、NETCONF或SNMP。
As discussed in Section 2.3.1.5, the Interface to the Routing System (I2RS) provides a programmatic way to access (for read and write) the routing state and policy information on routers in the network. The I2RS Client issues requests to routers in the network to establish or retrieve routing state. Those requests utilize the I2RS protocol, which will be based on a combination of NETCONF [RFC6241] and RESTCONF [RESTCONF] with some additional features.
如第2.3.1.5节所述，路由系统（I2RS）接口提供了一种编程方式，用于访问（用于读写）网络中路由器的路由状态和策略信息。I2RS客户端向网络中的路由器发出请求，以建立或检索路由状态。这些请求使用I2RS协议，该协议将基于NETCONF[RFC6241]和RESTCONF[RESTCONF]的组合以及一些附加功能。
The ABNO Controller needs to be able to consult the PCE to determine what services can be provisioned in the network. There is no reason why this interface cannot be based on standard PCEP as defined in [RFC5440].
ABNO控制器需要能够咨询PCE，以确定可以在网络中提供哪些服务。该接口没有理由不能基于[RFC5440]中定义的标准PCEP。
There are two interactions between the Virtual Network Topology Manager and the PCE:
虚拟网络拓扑管理器和PCE之间存在两种交互：
The first interaction is used when VNTM wants to determine what LSPs can be set up in a network: in this case, it uses the standard PCEP interface [RFC5440] to make path computation requests.
当VNTM想要确定可以在网络中设置哪些LSP时，使用第一次交互：在这种情况下，它使用标准PCEP接口[RFC5440]来发出路径计算请求。
The second interaction arises when a PCE determines that it cannot compute a requested path or notices that (according to some configured policy) a network is low on resources (for example, the capacity on some key link is nearly exhausted). In this case, the PCE may notify the VNTM, which may (again according to policy) act to construct more virtual topology. This second interface is not currently specified, although it may be that the protocol selected or designed to satisfy I2RS will provide suitable features (see Section 2.3.2.8); alternatively, an extension to the PCEP Notify message (PCNtf) [RFC5440] could be made.
当PCE确定它无法计算请求的路径或注意到（根据某些配置的策略）网络资源不足（例如，某个关键链路上的容量几乎耗尽）时，就会发生第二次交互。在这种情况下，PCE可以通知VNTM，VNTM可以（同样根据策略）构造更多虚拟拓扑。目前未规定第二个接口，尽管为满足I2RS而选择或设计的协议可能会提供合适的功能（见第2.3.2.8节）；或者，可以对PCEP通知消息（PCNtf）[RFC5440]进行扩展。
The north-bound interface from the ABNO Controller is used by the NMS, OSS, and Application Service Coordinator to request services in the network in support of applications. The interface will also need to be able to report the asynchronous completion of service requests and convey changes in the status of services.
来自ABNO控制器的北向接口被NMS、OSS和应用程序服务协调员用于请求网络中的服务以支持应用程序。接口还需要能够报告服务请求的异步完成，并传递服务状态的更改。
This interface will also need strong capabilities for security, authentication, and policy.
该接口还需要强大的安全、身份验证和策略功能。
This interface is not currently specified. It needs to be a transactional interface that supports the specification of abstract services with adequate flexibility to facilitate easy extension and yet be concise and easily parsable.
当前未指定此接口。它需要是一个事务接口，支持抽象服务的规范，并具有足够的灵活性，以便于扩展，同时简洁且易于分析。
It is possible that the protocol designed to satisfy I2RS will provide suitable features (see Section 2.3.2.8).
设计用于满足I2RS的协议可能会提供合适的功能（见第2.3.2.8节）。
Under some circumstances, the ABNO Controller may make requests directly to the Provisioning Manager. For example, if the Provisioning Manager is acting as an SDN Controller, then the ABNO Controller may use one of the APIs defined to allow requests to be made to the SDN Controller (such as the Floodlight REST API [Flood]). Alternatively, since the Provisioning Manager may also receive instructions from a Stateful PCE, the use of PCEP extensions might be appropriate in some cases [PCE-Init-LSP].
在某些情况下，ABNO控制器可能会直接向供应管理器发出请求。例如，如果供应管理器充当SDN控制器，则ABNO控制器可以使用定义为允许向SDN控制器发出请求的API之一（例如泛光灯REST API[Flood]）。或者，由于供应管理器还可以从有状态PCE接收指令，因此在某些情况下使用PCEP扩展可能是合适的[PCE Init LSP]。
As described in Section 2.3.1.4 and throughout this document, policy forms a critical component of the ABNO architecture. The role of policy will include enforcing the following rules and requirements:
如第2.3.1.4节和本文件所述，政策是ABNO体系结构的关键组成部分。政策的作用包括执行以下规则和要求：
- Adding resources on demand should be gated by the authorized capability.
- 按需添加资源应该由授权的能力控制。
- Client microflows should not trigger server-layer setup or allocation.
- 客户端微流不应触发服务器层设置或分配。
- Accounting capabilities should be supported.
- 应支持会计能力。
- Security mechanisms for authorization of requests and capabilities are required.
- 需要用于授权请求和功能的安全机制。
Other policy-related functionality in the system might include the policy behavior of the routing and forwarding system, such as:
系统中其他与策略相关的功能可能包括路由和转发系统的策略行为，例如：
- ECMP behavior
- ECMP行为
- Classification of packets onto LSPs or QoS categories.
- 将数据包分类到LSP或QoS类别。
Various policy-capable architectures have been defined, including a framework for using policy with a PCE-enabled system [RFC5394]. However, the take-up of the IETF's Common Open Policy Service protocol (COPS) [RFC2748] has been poor.
已经定义了各种支持策略的体系结构，包括用于将策略与支持PCE的系统一起使用的框架[RFC5394]。然而，IETF的公共开放政策服务协议（COPS）[RFC2748]的使用率一直很低。
New work will be needed to define all of the policy interfaces within the ABNO architecture. Work will also be needed to determine which are internal interfaces and which may be external and so in need of a protocol specification. There is some discussion that the I2RS protocol may support the configuration and manipulation of policies.
需要新的工作来定义ABNO体系结构中的所有策略接口。还需要确定哪些是内部接口，哪些可能是外部接口，因此需要协议规范。有一些讨论认为I2RS协议可能支持策略的配置和操作。
The OAM Handler must interact with the network to perform several actions:
OAM处理程序必须与网络交互以执行多个操作：
- Enabling OAM function within the network.
- 在网络中启用OAM功能。
- Performing proactive OAM operations in the network.
- 在网络中执行主动式OAM操作。
- Receiving notifications of network events.
- 接收网络事件的通知。
Any of the configuration and programmatic interfaces described in Section 2.3.2.1 may serve this purpose. NETCONF notifications are described in [RFC5277], and OpenFlow supports a number of asynchronous event notifications [ONF]. Additionally, Syslog [RFC5424] is a protocol for reporting events from the network, and IP Flow Information Export (IPFIX) [RFC7011] is designed to allow network statistics to be aggregated and reported.
第2.3.2.1节中描述的任何配置和编程接口均可用于此目的。[RFC5277]中描述了NETCONF通知，OpenFlow支持许多异步事件通知[ONF]。此外，Syslog[RFC5424]是一种用于报告网络事件的协议，IP流信息导出（IPFIX）[RFC7011]旨在允许聚合和报告网络统计信息。
The OAM Handler also correlates events reported from the network and reports them onward to the ABNO Controller (which can apply the information to the recovery of services that it has provisioned) and to the NMS, OSS, and Application Service Coordinator. The reporting mechanism used here can be essentially the same as the mechanism used when events are reported from the network; no new protocol is needed, although new data models may be required for technology-independent OAM reporting.
OAM处理程序还将从网络报告的事件关联起来，并将其报告给ABNO控制器（该控制器可将信息应用于恢复其提供的服务）以及NMS、OSS和应用程序服务协调器。此处使用的报告机制基本上与从网络报告事件时使用的机制相同；虽然独立于技术的OAM报告可能需要新的数据模型，但不需要新的协议。
This section provides a number of examples of how the ABNO architecture can be applied to provide application-driven and NMS/OSS-driven network operations. The purpose of these examples is to give some concrete material to demonstrate the architecture so that it may be more easily comprehended, and to illustrate that the application of the architecture is achieved by "profiling" and by selecting only the relevant components and interfaces.
本节提供了一些示例，说明如何应用ABNO体系结构来提供应用程序驱动和NMS/OSS驱动的网络操作。这些示例的目的是提供一些具体材料来演示体系结构，以便更容易理解，并说明体系结构的应用是通过“分析”和仅选择相关组件和接口来实现的。
Similarly, it is not the intention that this section contain a complete list of all possible applications of ABNO. The examples are intended to broadly cover a number of applications that are commonly discussed, but this does not preclude other use cases.
同样，本节也无意包含ABNO所有可能应用的完整列表。这些示例旨在广泛地涵盖通常讨论的许多应用程序，但这并不排除其他用例。
The descriptions in this section are not fully detailed applicability statements for ABNO. It is anticipated that such applicability statements, for the use cases described and for other use cases, could be suitable material for separate documents.
本节中的描述并非ABNO的完整详细适用性声明。预计对于所描述的用例和其他用例，此类适用性声明可能适用于单独的文档。
The following use case describes how the ABNO framework can be used to set up an end-to-end MPLS service across multiple Autonomous Systems (ASes). Consider the simple network topology shown in Figure 2. The three ASes (ASa, ASb, and ASc) are connected at AS Border Routers (ASBRs) a1, a2, b1 through b4, c1, and c2. A source node (s) located in ASa is to be connected to a destination node (d) located in ASc. The optimal path for the LSP from s to d must be computed, and then the network must be triggered to set up the LSP.
以下用例描述了如何使用ABNO框架跨多个自治系统（ASE）建立端到端MPLS服务。考虑图2所示的简单网络拓扑结构。三个ASE（ASa、ASb和ASc）在AS边界路由器（ASBR）a1、a2、b1到b4、c1和c2处连接。位于ASa中的源节点将连接到位于ASc中的目标节点（d）。必须计算LSP从s到d的最佳路径，然后必须触发网络以设置LSP。
+--------------+ +-----------------+ +--------------+
|ASa | | ASb | | ASc |
| +--+ | | +--+ +--+ | | +--+ |
| |a1|-|-|-|b1| |b3|-|-|-|c1| |
| +-+ +--+ | | +--+ +--+ | | +--+ +-+ |
| |s| | | | | |d| |
| +-+ +--+ | | +--+ +--+ | | +--+ +-+ |
| |a2|-|-|-|b2| |b4|-|-|-|c2| |
| +--+ | | +--+ +--+ | | +--+ |
| | | | | |
+--------------+ +-----------------+ +--------------+
+--------------+ +-----------------+ +--------------+
|ASa | | ASb | | ASc |
| +--+ | | +--+ +--+ | | +--+ |
| |a1|-|-|-|b1| |b3|-|-|-|c1| |
| +-+ +--+ | | +--+ +--+ | | +--+ +-+ |
| |s| | | | | |d| |
| +-+ +--+ | | +--+ +--+ | | +--+ +-+ |
| |a2|-|-|-|b2| |b4|-|-|-|c2| |
| +--+ | | +--+ +--+ | | +--+ |
| | | | | |
+--------------+ +-----------------+ +--------------+
Figure 2: Inter-AS Domain Topology with Hierarchical PCE (Parent PCE)
图2：具有分层PCE（父PCE）的AS域间拓扑
The following steps are performed to deliver the service within the ABNO architecture:
执行以下步骤以在ABNO体系结构内提供服务：
1. Request Management
1. 请求管理
As shown in Figure 3, the NMS/OSS issues a request to the ABNO Controller for a path between s and d. The ABNO Controller verifies that the NMS/OSS has sufficient rights to make the service request.
如图3所示，NMS/OSS向ABNO控制器发出s和d之间路径的请求。ABNO控制器验证NMS/OSS是否有足够的权限发出服务请求。
+---------------------+
| NMS/OSS |
+----------+----------+
|
V
+--------+ +-----------+-------------+
| Policy +-->-+ ABNO Controller |
| Agent | | |
+--------+ +-------------------------+
+---------------------+
| NMS/OSS |
+----------+----------+
|
V
+--------+ +-----------+-------------+
| Policy +-->-+ ABNO Controller |
| Agent | | |
+--------+ +-------------------------+
Figure 3: ABNO Request Management
图3:ABNO请求管理
2. Service Path Computation with Hierarchical PCE
2. 基于层次PCE的业务路径计算
The ABNO Controller needs to determine an end-to-end path for the LSP. Since the ASes will want to maintain a degree of confidentiality about their internal resources and topology, they will not share a TED and each will have its own PCE. In such a situation, the Hierarchical PCE (H-PCE) architecture described in [RFC6805] is applicable.
ABNO控制器需要确定LSP的端到端路径。由于ASE希望对其内部资源和拓扑保持一定程度的机密性，因此他们不会共享TED，并且每个ASE都有自己的PCE。在这种情况下，[RFC6805]中描述的分层PCE（H-PCE）架构是适用的。
As shown in Figure 4, the ABNO Controller sends a request to the parent PCE for an end-to-end path. As described in [RFC6805], the parent PCE consults its TED, which shows the connectivity between
如图4所示，ABNO控制器向父PCE发送端到端路径请求。如[RFC6805]所述，父PCE咨询其TED，TED显示了
ASes. This helps it understand that the end-to-end path must cross each of ASa, ASb, and ASc, so it sends individual path computation requests to each of PCEs a, b, and c to determine the best options for crossing the ASes.
阿斯。这有助于它理解端到端路径必须跨越ASa、ASb和ASc中的每一个，因此它向每个PCE a、b和c发送单独的路径计算请求，以确定跨越ASE的最佳选项。
Each child PCE applies policy to the requests it receives to determine whether the request is to be allowed and to select the types of network resources that can be used in the computation result. For confidentiality reasons, each child PCE may supply its computation responses using a path key [RFC5520] to hide the details of the path segment it has computed.
每个子PCE对其接收的请求应用策略，以确定是否允许该请求，并选择可在计算结果中使用的网络资源类型。出于保密原因，每个子PCE可以使用路径键[RFC5520]来提供其计算响应，以隐藏其已计算的路径段的细节。
+-----------------+
| ABNO Controller |
+----+-------+----+
| A
V |
+--+-------+--+ +--------+
+--------+ | | | |
| Policy +-->-+ Parent PCE +---+ AS TED |
| Agent | | | | |
+--------+ +-+----+----+-+ +--------+
/ | \
/ | \
+-----+-+ +---+---+ +-+-----+
| | | | | |
| PCE a | | PCE b | | PCE c |
| | | | | |
+---+---+ +---+---+ +---+---+
| | |
+--+--+ +--+--+ +--+--+
| TEDa| | TEDb| | TEDc|
+-----+ +-----+ +-----+
+-----------------+
| ABNO Controller |
+----+-------+----+
| A
V |
+--+-------+--+ +--------+
+--------+ | | | |
| Policy +-->-+ Parent PCE +---+ AS TED |
| Agent | | | | |
+--------+ +-+----+----+-+ +--------+
/ | \
/ | \
+-----+-+ +---+---+ +-+-----+
| | | | | |
| PCE a | | PCE b | | PCE c |
| | | | | |
+---+---+ +---+---+ +---+---+
| | |
+--+--+ +--+--+ +--+--+
| TEDa| | TEDb| | TEDc|
+-----+ +-----+ +-----+
Figure 4: Path Computation Request with Hierarchical PCE
图4：分层PCE的路径计算请求
The parent PCE collates the responses from the children and applies its own policy to stitch them together into the best end-to-end path, which it returns as a response to the ABNO Controller.
父PCE整理来自子PCE的响应，并应用其自己的策略将它们缝合到最佳端到端路径中，并将其作为响应返回给ABNO控制器。
3. Provisioning the End-to-End LSP
3. 设置端到端LSP
There are several options for how the end-to-end LSP gets provisioned in the ABNO architecture. Some of these are described below.
对于如何在ABNO体系结构中配置端到端LSP，有几个选项。下面将介绍其中一些。
3a. Provisioning from the ABNO Controller with a Control Plane
3a。使用控制平面从ABNO控制器进行配置
Figure 5 shows how the ABNO Controller makes a request through the Provisioning Manager to establish the end-to-end LSP. As described in Section 2.3.2.6, these interactions can use the NETCONF protocol [RFC6241] or the extensions to PCEP described in [PCE-Init-LSP]. In either case, the provisioning request is sent to the head-end Label Switching Router (LSR), and that LSR signals in the control plane (using a protocol such as RSVP-TE [RFC3209]) to cause the LSP to be established.
图5显示了ABNO控制器如何通过Provisioning Manager发出建立端到端LSP的请求。如第2.3.2.6节所述，这些交互可以使用NETCONF协议[RFC6241]或[PCE Init LSP]中所述的PCEP扩展。在任一情况下，供应请求被发送到前端标签交换路由器（LSR），并且该LSR在控制平面中发出信号（使用诸如RSVP-TE[RFC3209]之类的协议）以导致建立LSP。
+-----------------+
| ABNO Controller |
+--------+--------+
|
V
+------+-------+
| Provisioning |
| Manager |
+------+-------+
|
V
+--------------------+------------------------+
/ Network \
+-------------------------------------------------+
+-----------------+
| ABNO Controller |
+--------+--------+
|
V
+------+-------+
| Provisioning |
| Manager |
+------+-------+
|
V
+--------------------+------------------------+
/ Network \
+-------------------------------------------------+
Figure 5: Provisioning the End-to-End LSP
图5：配置端到端LSP
3b. Provisioning through Programming Network Resources
3b。通过编程网络资源进行资源调配
Another option is that the LSP is provisioned hop by hop from the Provisioning Manager using a mechanism such as ForCES [RFC5810] or OpenFlow [ONF] as described in Section 2.3.2.6. In this case, the picture is the same as that shown in Figure 5. The interaction between the ABNO Controller and the Provisioning Manager will be PCEP or NETCONF as described in option 3a, and the Provisioning Manager will be responsible for fanning out the requests to the individual network elements.
另一种选择是，使用第2.3.2.6节所述的ForCES[RFC5810]或OpenFlow[ONF]等机制，从供应管理器逐跳供应LSP。在这种情况下，图片与图5所示相同。ABNO控制器和供应管理器之间的交互将是PCEP或NETCONF，如选项3a所述，供应管理器将负责将请求分散到各个网络元件。
3c. Provisioning with an Active Parent PCE
3c。使用活动父PCE进行资源调配
The Active PCE is described in Section 2.3.1.7, based on the concepts expressed in [PCE-Init-LSP]. In this approach, the process described in option 3a is modified such that the PCE issues a direct PCEP command to the network, without a response being first returned to the ABNO Controller.
第2.3.1.7节根据[PCE Init LSP]中表达的概念描述了有源PCE。在该方法中，修改选项3a中描述的过程，使得PCE向网络发出直接PCEP命令，而不首先将响应返回到ABNO控制器。
This situation is shown in Figure 6 and could be modified so that the Provisioning Manager still programs the individual network elements as described in option 3b.
这种情况如图6所示，可以进行修改，以便Provisioning Manager仍然按照选项3b中所述对各个网络元素进行编程。
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--+----------+ +--------------+
+--------+ | | | Provisioning |
| Policy +-->-+ Parent PCE +---->----+ Manager |
| Agent | | | | |
+--------+ +-+----+----+-+ +-----+--------+
/ | \ |
/ | \ |
+-----+-+ +---+---+ +-+-----+ V
| | | | | | |
| PCE a | | PCE b | | PCE c | |
| | | | | | |
+-------+ +-------+ +-------+ |
|
+--------------------------------+------------+
/ Network \
+-------------------------------------------------+
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--+----------+ +--------------+
+--------+ | | | Provisioning |
| Policy +-->-+ Parent PCE +---->----+ Manager |
| Agent | | | | |
+--------+ +-+----+----+-+ +-----+--------+
/ | \ |
/ | \ |
+-----+-+ +---+---+ +-+-----+ V
| | | | | | |
| PCE a | | PCE b | | PCE c | |
| | | | | | |
+-------+ +-------+ +-------+ |
|
+--------------------------------+------------+
/ Network \
+-------------------------------------------------+
Figure 6: LSP Provisioning with an Active PCE
图6：使用活动PCE的LSP配置
3d. Provisioning with Active Child PCEs and Segment Stitching
3d。使用活动子PCE和段缝合进行资源调配
A mixture of the approaches described in options 3b and 3c can result in a combination of mechanisms to program the network to provide the end-to-end LSP. Figure 7 shows how each child PCE can be an Active PCE responsible for setting up an edge-to-edge LSP segment across one of the ASes. The ABNO Controller then uses the Provisioning Manager to program the inter-AS connections using ForCES or OpenFlow, and the LSP segments are stitched together following the ideas described in [RFC5150]. Philosophers may debate whether the parent PCE
选项3b和3c中描述的方法的混合可以导致对网络进行编程以提供端到端LSP的机制的组合。图7显示了每个子PCE如何成为一个活动PCE，负责跨一个ASE设置边到边LSP段。ABNO控制器然后使用供应管理器使用ForCES或OpenFlow对inter-AS连接进行编程，并按照[RFC5150]中描述的思路将LSP段缝合在一起。哲学家们可能会争论父母的PCE
in this model is active (instructing the children to provision LSP segments) or passive (requesting path segments that the children provision).
在该模型中，是主动的（指示子级提供LSP段）或被动的（请求子级提供的路径段）。
+-----------------+
| ABNO Controller +-------->--------+
+----+-------+----+ |
| A |
V | |
+--+-------+--+ |
+--------+ | | |
| Policy +-->-+ Parent PCE | |
| Agent | | | |
+--------+ ++-----+-----++ |
/ | \ |
/ | \ |
+---+-+ +--+--+ +-+---+ |
| | | | | | |
|PCE a| |PCE b| |PCE c| |
| | | | | | V
+--+--+ +--+--+ +---+-+ |
| | | |
V V V |
+----------+-+ +------------+ +-+----------+ |
|Provisioning| |Provisioning| |Provisioning| |
|Manager | |Manager | |Manager | |
+-+----------+ +-----+------+ +-----+------+ |
| | | |
V V V |
+--+-----+ +----+---+ +--+-----+ |
/ AS a \=====/ AS b \=====/ AS c \ |
+------------+ A +------------+ A +------------+ |
| | |
+-----+----------------+-----+ |
| Provisioning Manager +----<-------+
+----------------------------+
+-----------------+
| ABNO Controller +-------->--------+
+----+-------+----+ |
| A |
V | |
+--+-------+--+ |
+--------+ | | |
| Policy +-->-+ Parent PCE | |
| Agent | | | |
+--------+ ++-----+-----++ |
/ | \ |
/ | \ |
+---+-+ +--+--+ +-+---+ |
| | | | | | |
|PCE a| |PCE b| |PCE c| |
| | | | | | V
+--+--+ +--+--+ +---+-+ |
| | | |
V V V |
+----------+-+ +------------+ +-+----------+ |
|Provisioning| |Provisioning| |Provisioning| |
|Manager | |Manager | |Manager | |
+-+----------+ +-----+------+ +-----+------+ |
| | | |
V V V |
+--+-----+ +----+---+ +--+-----+ |
/ AS a \=====/ AS b \=====/ AS c \ |
+------------+ A +------------+ A +------------+ |
| | |
+-----+----------------+-----+ |
| Provisioning Manager +----<-------+
+----------------------------+
Figure 7: LSP Provisioning with Active Child PCEs and Stitching
图7：带有活动子PCE和缝合的LSP供应
4. Verification of Service
4. 核实服务
The ABNO Controller will need to ascertain that the end-to-end LSP has been set up as requested. In the case of a control plane being used to establish the LSP, the head-end LSR may send a notification (perhaps using PCEP) to report successful setup, but to be sure that the LSP is up, the ABNO Controller will request the OAM Handler to perform Continuity Check OAM in the data plane and report back that the LSP is ready to carry traffic.
ABNO控制器需要确定端到端LSP已按要求设置。在使用控制平面建立LSP的情况下，前端LSR可以发送通知（可能使用PCEP）以报告成功的设置，但为了确保LSP启动，ABNO控制器将请求OAM处理程序在数据平面中执行连续性检查OAM，并报告LSP已准备好承载流量。
5. Notification of Service Fulfillment
5. 服务履行通知
Finally, when the ABNO Controller is satisfied that the requested service is ready to carry traffic, it will notify the NMS/OSS. The delivery of the service may be further checked through auditing the network, as described in Section 2.3.2.7.
最后，当ABNO控制器确信请求的服务已准备好承载流量时，它将通知NMS/OSS。如第2.3.2.7节所述，可通过审计网络进一步检查服务的提供情况。
Networks are typically constructed using multiple layers. These layers represent separations of administrative regions or of technologies and may also represent a distinction between client and server networking roles.
网络通常采用多层结构。这些层表示管理区域或技术的分离，也可能表示客户端和服务器网络角色之间的区别。
It is preferable to coordinate network resource control and utilization (i.e., consideration and control of multiple layers), rather than controlling and optimizing resources at each layer independently. This facilitates network efficiency and network automation and may be defined as inter-layer traffic engineering.
最好是协调网络资源控制和利用（即，考虑和控制多层），而不是单独控制和优化每一层的资源。这有利于网络效率和网络自动化，可以定义为层间流量工程。
The PCE architecture supports inter-layer traffic engineering [RFC5623] and, in combination with the ABNO architecture, provides a suite of capabilities for network resource coordination across multiple layers.
PCE体系结构支持层间流量工程[RFC5623]，并与ABNO体系结构相结合，为跨多个层的网络资源协调提供了一套功能。
The following use case demonstrates ABNO used to coordinate allocation of server-layer network resources to create virtual topology in a client-layer network in order to satisfy a request for end-to-end client-layer connectivity. Consider the simple multi-layer network in Figure 8.
下面的用例演示ABNO用于协调服务器层网络资源的分配，以在客户端层网络中创建虚拟拓扑，以满足端到端客户端层连接的请求。考虑图8中的简单多层网络。
+--+ +--+ +--+ +--+ +--+ +--+
|P1|---|P2|---|P3| |P4|---|P5|---|P6|
+--+ +--+ +--+ +--+ +--+ +--+
\ /
\ /
+--+ +--+ +--+
|L1|--|L2|--|L3|
+--+ +--+ +--+
+--+ +--+ +--+ +--+ +--+ +--+
|P1|---|P2|---|P3| |P4|---|P5|---|P6|
+--+ +--+ +--+ +--+ +--+ +--+
\ /
\ /
+--+ +--+ +--+
|L1|--|L2|--|L3|
+--+ +--+ +--+
Figure 8: Multi-Layer Network
图8：多层网络
There are six packet-layer routers (P1 through P6) and three optical-layer lambda switches (L1 through L3). There is connectivity in the packet layer between routers P1, P2, and P3, and also between routers P4, P5, and P6, but there is no packet-layer connectivity between these two islands of routers, perhaps because of a network failure or perhaps because all existing bandwidth between the islands has
有六个包层路由器（P1到P6）和三个光学层lambda交换机（L1到L3）。路由器P1、P2和P3之间以及路由器P4、P5和P6之间的分组层中存在连接，但是这两个路由器孤岛之间不存在分组层连接，可能是因为网络故障，或者可能是因为孤岛之间的所有现有带宽都已断开
already been used up. However, there is connectivity in the optical layer between switches L1, L2, and L3, and the optical network is connected out to routers P3 and P4 (they have optical line cards). In this example, a packet-layer connection (an MPLS LSP) is desired between P1 and P6.
已经用完了。然而，在交换机L1、L2和L3之间的光层中存在连接，并且光网络连接到路由器P3和P4（它们具有光线路卡）。在此示例中，在P1和P6之间需要分组层连接（MPLS LSP）。
In the ABNO architecture, the following steps are performed to deliver the service.
在ABNO体系结构中，执行以下步骤来提供服务。
1. Request Management
1. 请求管理
As shown in Figure 9, the Application Service Coordinator issues a request for connectivity from P1 to P6 in the packet-layer network. That is, the Application Service Coordinator requests an MPLS LSP with a specific bandwidth to carry traffic for its application. The ABNO Controller verifies that the Application Service Coordinator has sufficient rights to make the service request.
如图9所示，应用程序服务协调器在数据包层网络中发出从P1到P6的连接请求。也就是说，应用服务协调器请求具有特定带宽的MPLS LSP来承载其应用的流量。ABNO控制器验证应用程序服务协调器是否具有发出服务请求的足够权限。
+---------------------------+
| Application Service |
| Coordinator |
+-------------+-------------+
|
V
+------+ +------------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +-------------------------+
+---------------------------+
| Application Service |
| Coordinator |
+-------------+-------------+
|
V
+------+ +------------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +-------------------------+
Figure 9: Application Service Coordinator Request Management
图9：应用程序服务协调器请求管理
2. Service Path Computation in the Packet Layer
2. 分组层的业务路径计算
The ABNO Controller sends a path computation request to the packet-layer PCE to compute a suitable path for the requested LSP, as shown in Figure 10. The PCE uses the appropriate policy for the request and consults the TED for the packet layer. It determines that no path is immediately available.
ABNO控制器向数据包层PCE发送路径计算请求，为请求的LSP计算合适的路径，如图10所示。PCE对请求使用适当的策略，并为分组层咨询TED。它确定没有立即可用的路径。
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--------+ +--+-----------+ +--------+
| Policy +-->--+ Packet-Layer +---+ Packet |
| Agent | | PCE | | TED |
+--------+ +--------------+ +--------+
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--------+ +--+-----------+ +--------+
| Policy +-->--+ Packet-Layer +---+ Packet |
| Agent | | PCE | | TED |
+--------+ +--------------+ +--------+
Figure 10: Path Computation Request
图10：路径计算请求
3. Invocation of VNTM and Path Computation in the Optical Layer
3. VNTM调用与光层路径计算
After the path computation failure in step 2, instead of notifying the ABNO Controller of the failure, the PCE invokes the VNTM to see whether it can create the necessary link in the virtual network topology to bridge the gap.
在步骤2中的路径计算失败后，PCE不通知ABNO控制器该失败，而是调用VNTM以查看它是否可以在虚拟网络拓扑中创建必要的链路以桥接该间隙。
As shown in Figure 11, the packet-layer PCE reports the connectivity problem to the VNTM, and the VNTM consults policy to determine what it is allowed to do. Assuming that the policy allows it, the VNTM asks the optical-layer PCE to find a path across the optical network that could be provisioned to provide a virtual link for the packet layer. In addressing this request, the optical-layer PCE consults a TED for the optical-layer network.
如图11所示，数据包层PCE向VNTM报告连接问题，VNTM咨询策略以确定允许它做什么。假设该策略允许，VNTM请求光学层PCE在光网络上找到一条路径，该路径可以被配置为为为分组层提供虚拟链路。在处理该请求时，光学层PCE咨询光学层网络的TED。
+------+
+--------+ | | +--------------+
| Policy +-->--+ VNTM +--<--+ Packet-Layer |
| Agent | | | | PCE |
+--------+ +---+--+ +--------------+
|
V
+---------------+ +---------+
| Optical-Layer +---+ Optical |
| PCE | | TED |
+---------------+ +---------+
+------+
+--------+ | | +--------------+
| Policy +-->--+ VNTM +--<--+ Packet-Layer |
| Agent | | | | PCE |
+--------+ +---+--+ +--------------+
|
V
+---------------+ +---------+
| Optical-Layer +---+ Optical |
| PCE | | TED |
+---------------+ +---------+
Figure 11: Invocation of VNTM and Optical-Layer Path Computation
图11:VNTM调用和光学层路径计算
4. Provisioning in the Optical Layer
4. 光层中的资源调配
Once a path has been found across the optical-layer network, it needs to be provisioned. The options follow those in step 3 of Section 3.1. That is, provisioning can be initiated by the optical-layer PCE or by its user, the VNTM. The command can be
一旦在光层网络中找到路径，就需要对其进行配置。选项遵循第3.1节步骤3中的选项。也就是说，供应可以由光学层PCE或其用户VNTM发起。命令可以是
sent to the head end of the optical LSP (P3) so that the control plane (for example, GMPLS RSVP-TE [RFC3473]) can be used to provision the LSP. Alternatively, the network resources can be provisioned directly, using any of the mechanisms described in Section 2.3.2.6.
发送到光学LSP（P3）的前端，以便可以使用控制平面（例如，GMPLS RSVP-TE[RFC3473]）来提供LSP。或者，可以使用第2.3.2.6节中描述的任何机制直接供应网络资源。
5. Creation of Virtual Topology in the Packet Layer
5. 在数据包层创建虚拟拓扑
Once the LSP has been set up in the optical layer, it can be made available in the packet layer as a virtual link. If the GMPLS signaling used the mechanisms described in [RFC6107], this process can be automated within the control plane; otherwise, it may require a specific instruction to the head-end router of the optical LSP (for example, through I2RS).
一旦LSP在光学层中建立，它就可以在分组层中作为虚拟链路使用。如果GMPLS信令使用[RFC6107]中所述的机制，则该过程可在控制平面内实现自动化；否则，可能需要向光学LSP的前端路由器发出特定指令（例如，通过I2RS）。
Once the virtual link is created as shown in Figure 12, it is advertised in the IGP for the packet-layer network, and the link will appear in the TED for the packet-layer network.
一旦如图12所示创建了虚拟链路，它将在分组层网络的IGP中公布，并且该链路将出现在分组层网络的TED中。
+--------+
| Packet |
| TED |
+------+-+
A
|
+--+ +--+
|P3|....................|P4|
+--+ +--+
\ /
\ /
+--+ +--+ +--+
|L1|--|L2|--|L3|
+--+ +--+ +--+
+--------+
| Packet |
| TED |
+------+-+
A
|
+--+ +--+
|P3|....................|P4|
+--+ +--+
\ /
\ /
+--+ +--+ +--+
|L1|--|L2|--|L3|
+--+ +--+ +--+
Figure 12: Advertisement of a New Virtual Link
图12：新虚拟链接的广告
6. Path Computation Completion and Provisioning in the Packet Layer
6. 包层中的路径计算完成和供应
Now there are sufficient resources in the packet-layer network. The PCE for the packet layer can complete its work, and the MPLS LSP can be provisioned as described in Section 3.1.
现在在包层网络中有足够的资源。分组层的PCE可以完成其工作，并且可以按照第3.1节中的描述配置MPLS LSP。
7. Verification and Notification of Service Fulfillment
7. 服务履行的验证和通知
As discussed in Section 3.1, the ABNO Controller will need to verify that the end-to-end LSP has been correctly established before reporting service fulfillment to the Application Service Coordinator.
如第3.1节所述，ABNO控制器需要在向应用程序服务协调员报告服务完成情况之前，验证端到端LSP是否已正确建立。
Furthermore, it is highly likely that service verification will be necessary before the optical-layer LSP can be put into service as a virtual link. Thus, the VNTM will need to coordinate with the OAM Handler to ensure that the LSP is ready for use.
此外，在光学层LSP可以作为虚拟链路投入服务之前，很可能需要进行服务验证。因此，VNTM需要与OAM处理程序协调，以确保LSP已准备好使用。
In order to support new and emerging cloud-based applications, such as real-time data backup, virtual machine migration, server clustering, or load reorganization, the dynamic provisioning and allocation of IT resources and the interconnection of multiple, remote Data Centers (DCs) is a growing requirement.
为了支持新的和新兴的基于云的应用程序，如实时数据备份、虚拟机迁移、服务器群集或负载重组，IT资源的动态调配和分配以及多个远程数据中心（DC）的互连是一个日益增长的需求。
These operations require traffic being delivered between data centers, and, typically, the connections providing such inter-DC connectivity are provisioned using static circuits or dedicated leased lines, leading to an inefficiency in terms of resource utilization. Moreover, a basic requirement is that such a group of remote DCs can be operated logically as one.
这些操作需要在数据中心之间传输通信量，并且，通常，提供这种DC间连接的连接使用静态电路或专用租用线路进行配置，从而导致资源利用效率低下。此外，一个基本要求是，这样一组远程DCs可以作为一个DCs进行逻辑操作。
In such environments, the data plane technology is operator and provider dependent. Their customers may rent lambda switch capable (LSC), packet switch capable (PSC), or time division multiplexing (TDM) services, and the application and usage of the ABNO architecture and Controller enable the required dynamic end-to-end network service provisioning, regardless of underlying service and transport layers.
在这种环境中，数据平面技术依赖于运营商和提供商。他们的客户可以租用支持lambda交换机（LSC）、支持分组交换机（PSC）或时分复用（TDM）服务，ABNO体系结构和控制器的应用和使用可以实现所需的动态端到端网络服务供应，而不管底层服务和传输层如何。
Consequently, the interconnection of DCs may involve the operation, control, and management of heterogeneous environments: each DC site and the metro-core network segment used to interconnect them, with regard to not only the underlying data plane technology but also the control plane. For example, each DC site or domain could be controlled locally in a centralized way (e.g., via OpenFlow [ONF]), whereas the metro-core transport infrastructure is controlled by GMPLS. Although OpenFlow is specially adapted to single-domain intra-DC networks (packet-level control, lots of routing exceptions), a standardized GMPLS-based architecture would enable dynamic optical resource allocation and restoration in multi-domain (e.g., multi-vendor) core networks interconnecting distributed data centers.
因此，DCs的互连可能涉及异构环境的操作、控制和管理：每个DC站点和用于互连它们的城域核心网段，不仅涉及底层数据平面技术，还涉及控制平面。例如，每个DC站点或域可以通过集中方式（例如，通过OpenFlow[ONF]）进行本地控制，而地铁核心运输基础设施则由GMPLS控制。尽管OpenFlow特别适用于单域DC内部网络（数据包级控制，大量路由例外），但基于标准化GMPLS的体系结构将能够在互连分布式数据中心的多域（例如，多供应商）核心网络中实现动态光资源分配和恢复。
The application of an ABNO architecture and related procedures would involve the following aspects:
ABNO架构和相关程序的应用将涉及以下方面：
1. Request from the Application Service Coordinator or NMS
1. 来自应用程序服务协调器或NMS的请求
As shown in Figure 13, the ABNO Controller receives a request from the Application Service Coordinator or from the NMS, in order to create a new end-to-end connection between two end points. The actual addressing of these end points is discussed in the next section. The ABNO Controller asks the PCE for a path between these two end points, after considering any applicable policy as defined by the Policy Agent (see Figure 1).
如图13所示，ABNO控制器接收来自应用程序服务协调器或NMS的请求，以便在两个端点之间创建新的端到端连接。下一节将讨论这些端点的实际寻址。ABNO控制器在考虑策略代理定义的任何适用策略后，向PCE询问这两个端点之间的路径（见图1）。
+---------------------------+
| Application Service |
| Coordinator or NMS |
+-------------+-------------+
|
V
+------+ +------------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +-------------------------+
+---------------------------+
| Application Service |
| Coordinator or NMS |
+-------------+-------------+
|
V
+------+ +------------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +-------------------------+
Figure 13: Application Service Coordinator Request Management
图13：应用程序服务协调器请求管理
2. Address Mapping
2. 地址映射
In order to compute an end-to-end path, the PCE needs to have a unified view of the overall topology, which means that it has to consider and identify the actual end points with regard to the client network addresses. The ABNO Controller and/or the PCE may need to translate or map addresses from different address spaces. Depending on how the topology information is disseminated and gathered, there are two possible scenarios:
为了计算端到端路径，PCE需要对整个拓扑结构有统一的视图，这意味着它必须考虑和识别关于客户端网络地址的实际端点。ABNO控制器和/或PCE可能需要翻译或映射来自不同地址空间的地址。根据拓扑信息的传播和收集方式，有两种可能的情况：
2a. The Application Layer Knows the Client Network Layer
2a。应用层知道客户端网络层
Entities belonging to the application layer may have an interface with the TED or with an ALTO Server allowing those entities to map the high-level end points to network addresses. The mechanism used to enable this address correlation is out of scope for this document but relies on direct interfaces to other ABNO components in addition to the interface to the ABNO Controller.
属于应用层的实体可以具有与TED或ALTO服务器的接口，允许这些实体将高级端点映射到网络地址。用于启用此地址关联的机制不在本文档的范围内，但除了与ABNO控制器的接口外，还依赖于与其他ABNO组件的直接接口。
In this scenario, the request from the NMS or Application Service Coordinator contains addresses in the client-layer network. Therefore, when the ABNO Controller requests the PCE to compute a path between two end points, the PCE is able to use the supplied addresses, compute the path, and continue the workflow in communication with the Provisioning Manager.
在这种情况下，来自NMS或应用程序服务协调器的请求包含客户端层网络中的地址。因此，当ABNO控制器请求PCE计算两个端点之间的路径时，PCE能够使用提供的地址，计算路径，并与供应管理器通信继续工作流。
2b. The Application Layer Does Not Know the Client Network Layer
2b。应用程序层不知道客户端网络层
In this case, when the ABNO Controller receives a request from the NMS or Application Service Coordinator, the request contains only identifiers from the application-layer address space. In order for the PCE to compute an end-to-end path, these identifiers must be converted to addresses in the client-layer network. This translation can be performed by the ABNO Controller, which can access the TED and ALTO databases allowing the path computation request that it sends to the PCE to simply be contained within one network and TED. Alternatively, the computation request could use the application-layer identifiers, leaving the job of address mapping to the PCE.
在这种情况下，当ABNO控制器接收到来自NMS或应用服务协调器的请求时，该请求仅包含来自应用层地址空间的标识符。为了让PCE计算端到端路径，必须将这些标识符转换为客户端层网络中的地址。该转换可由ABNO控制器执行，该控制器可访问TED和ALTO数据库，从而允许其发送给PCE的路径计算请求仅包含在一个网络和TED中。或者，计算请求可以使用应用层标识符，将地址映射的工作留给PCE。
Note that in order to avoid any confusion both approaches in this scenario require clear identification of the address spaces that are in use.
请注意，为了避免任何混淆，此场景中的两种方法都需要明确标识正在使用的地址空间。
3. Provisioning Process
3. 供应过程
Once the path has been obtained, the Provisioning Manager receives a high-level provisioning request to provision the service. Since, in the considered use case, the network elements are not necessarily configured using the same protocol, the end-to-end path is split into segments, and the ABNO Controller coordinates or orchestrates the establishment by adapting and/or translating the abstract provisioning request to concrete segment requests by means of a VNTM or PCE that issues the corresponding commands or instructions. The provisioning may involve configuring the data plane elements directly or delegating the establishment of the underlying connection to a dedicated control plane instance responsible for that segment.
获取路径后，Provisioning Manager将收到一个高级配置请求来配置服务。由于在所考虑的用例中，网络元件不一定使用相同的协议进行配置，因此端到端路径被分割成段，ABNO控制器通过发出相应命令或指令的VNTM或PCE调整和/或将抽象供应请求转换为具体段请求来协调或协调建立。供应可能涉及直接配置数据平面元素或将基础连接的建立委托给负责该段的专用控制平面实例。
The Provisioning Manager could use a number of mechanisms to program the network elements, as shown in Figure 14. It learns which technology is used for the actual provisioning at each segment by either manual configuration or discovery.
Provisioning Manager可以使用多种机制对网络元素进行编程，如图14所示。它通过手动配置或发现，了解在每个细分市场上实际供应所使用的技术。
+-----------------+
| ABNO Controller |
+-------+---------+
|
|
V
+------+ +------+-------+
| VNTM +--<--+ PCE |
+---+--+ +------+-------+
| |
V V
+-----+---------------+------------+
| Provisioning Manager |
+----------------------------------+
| | | | |
V | V | V
OpenFlow V ForCES V PCEP
NETCONF SNMP
+-----------------+
| ABNO Controller |
+-------+---------+
|
|
V
+------+ +------+-------+
| VNTM +--<--+ PCE |
+---+--+ +------+-------+
| |
V V
+-----+---------------+------------+
| Provisioning Manager |
+----------------------------------+
| | | | |
V | V | V
OpenFlow V ForCES V PCEP
NETCONF SNMP
Figure 14: Provisioning Process
图14：供应流程
4. Verification and Notification of Service Fulfillment
4. 服务履行的验证和通知
Once the end-to-end connectivity service has been provisioned, and after the verification of the correct operation of the service, the ABNO Controller needs to notify the Application Service Coordinator or NMS.
提供端到端连接服务后，在验证服务的正确操作后，ABNO控制器需要通知应用程序服务协调员或NMS。
A number of different services depend on the establishment of a new LSP so that traffic supported by an existing LSP can be switched with little or no disruption. This section describes those use cases, presents a generic model for make-before-break within the ABNO architecture, and shows how each use case can be supported by using elements of the generic model.
许多不同的服务取决于新LSP的建立，因此现有LSP支持的流量可以在很少或没有中断的情况下切换。本节描述了这些用例，介绍了ABNO体系结构中先造后破的通用模型，并展示了如何通过使用通用模型的元素来支持每个用例。
Make-before-break is a mechanism supported in RSVP-TE signaling where a new LSP is set up before the LSP it replaces is torn down [RFC3209]. This process has several benefits in situations such as reoptimization of in-service LSPs.
先通后断是RSVP-TE信令中支持的一种机制，其中在拆除其替换的LSP之前设置新LSP[RFC3209]。在诸如重新优化在用LSP的情况下，此过程有几个好处。
The process is simple, and the example shown in Figure 15 utilizes a Stateful PCE [Stateful-PCE] to monitor the network and take reoptimization actions when necessary. In this process, a service request is made to the ABNO Controller by a requester such as the OSS. The service request indicates that the LSP should be reoptimized under specific conditions according to policy. This allows the ABNO Controller to manage the sequence and prioritization of reoptimizing multiple LSPs using elements of Global Concurrent Optimization (GCO) as described in Section 3.4, and applying policies across the network so that, for instance, LSPs for delay-sensitive services are reoptimized first.
该过程很简单，图15中所示的示例利用有状态PCE[有状态PCE]来监控网络，并在必要时采取重新优化操作。在此过程中，请求者（如OSS）向ABNO控制器发出服务请求。服务请求表明LSP应根据策略在特定条件下重新优化。这允许ABNO控制器管理使用第3.4节所述的全局并发优化（GCO）元素重新优化多个LSP的顺序和优先级，并在网络上应用策略，以便首先重新优化延迟敏感服务的LSP。
The ABNO Controller commissions the PCE to compute and set up the initial path.
ABNO控制器委托PCE计算并设置初始路径。
Over time, the PCE monitors the changes in the network as reflected in the TED, and according to the configured policy may compute and set up a replacement path, using make-before-break within the network.
随着时间的推移，PCE监控TED中反映的网络变化，并且根据配置的策略，可以使用网络中的先通后断来计算和设置替换路径。
Once the new path has been set up and the network reports that it is being used correctly, the PCE tears down the old path and may report the reoptimization event to the ABNO Controller.
一旦建立了新路径，并且网络报告它正被正确使用，PCE将拆除旧路径，并可能向ABNO控制器报告重新优化事件。
+---------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+----------------------+----------------------+
|
+------------+------------+
| ABNO Controller |
+------------+------------+
|
+------+ +-------+-------+ +-----+
|Policy+-----+ PCE +-----+ TED |
|Agent | +-------+-------+ +-----+
+------+ |
|
+----------------------+----------------------+
/ Network \
+-------------------------------------------------+
+---------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+----------------------+----------------------+
|
+------------+------------+
| ABNO Controller |
+------------+------------+
|
+------+ +-------+-------+ +-----+
|Policy+-----+ PCE +-----+ TED |
|Agent | +-------+-------+ +-----+
+------+ |
|
+----------------------+----------------------+
/ Network \
+-------------------------------------------------+
Figure 15: The Make-before-Break Process
图15：先通后断流程
Make-before-break may also be used to repair a failed LSP where there is a desire to retain resources along some of the path, and where there is the potential for other LSPs to "steal" the resources if the
“先通后断”还可用于修复出现故障的LSP，其中希望保留某些路径上的资源，并且如果出现以下情况，则其他LSP可能会“窃取”资源：
failed LSP is torn down first. Unlike the example in Section 3.3.1, this case addresses a situation where the service is interrupted, but this interruption arises from the break in service introduced by the network failure. Obviously, in the case of a point-to-multipoint LSP, the failure might only affect part of the tree and the disruption will only be to a subset of the destination leaves so that a make-before-break restoration approach will not cause disruption to the leaves that were not affected by the original failure.
失败的LSP首先被拆除。与第3.3.1节中的示例不同，这种情况解决了服务中断的情况，但这种中断是由网络故障引起的服务中断引起的。显然，在点对多点LSP的情况下，故障可能只影响树的一部分，中断只会影响到目标叶的子集，因此先通后断恢复方法不会对未受原始故障影响的叶造成中断。
Figure 16 shows the components that interact for this use case. A service request is made to the ABNO Controller by a requester such as the OSS. The service request indicates that the LSP may be restored after failure and should attempt to reuse as much of the original path as possible.
图16显示了与此用例交互的组件。服务请求由请求者（如OSS）向ABNO控制器发出。服务请求表明LSP可能在故障后恢复，并应尝试尽可能多地重用原始路径。
The ABNO Controller commissions the PCE to compute and set up the initial path. The ABNO Controller also requests the OAM Handler to initiate OAM on the LSP and to monitor the results.
ABNO控制器委托PCE计算并设置初始路径。ABNO控制器还请求OAM处理程序在LSP上启动OAM并监视结果。
At some point, the network reports a fault to the OAM Handler, which notifies the ABNO Controller.
在某个时刻，网络向OAM处理程序报告故障，OAM处理程序通知ABNO控制器。
The ABNO Controller commissions the PCE to compute a new path, reusing as much of the original path as possible, and the PCE sets up the new LSP.
ABNO控制器委托PCE计算新路径，尽可能重用原始路径，PCE设置新LSP。
Once the new path has been set up and the network reports that it is being used correctly, the ABNO Controller instructs the PCE to tear down the old path.
一旦建立了新路径，并且网络报告正确使用了该路径，ABNO控制器就会指示PCE拆除旧路径。
+---------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+----------------------+----------------------+
|
+------------+------------+ +-------+
| ABNO Controller +---+ OAM |
+------------+------------+ |Handler|
| +---+---+
+-------+-------+ |
| PCE | |
+-------+-------+ |
| |
+----------------------+--------------------+-+
/ Network \
+-------------------------------------------------+
+---------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+----------------------+----------------------+
|
+------------+------------+ +-------+
| ABNO Controller +---+ OAM |
+------------+------------+ |Handler|
| +---+---+
+-------+-------+ |
| PCE | |
+-------+-------+ |
| |
+----------------------+--------------------+-+
/ Network \
+-------------------------------------------------+
Figure 16: The Make-before-Break Restoration Process
图16：先通后断恢复过程
In a more complicated use case, an LSP may be monitored for a number of attributes, such as delay and jitter. When the LSP falls below a threshold, the traffic may be moved to another LSP that offers the desired (or at least a better) quality of service. To achieve this, it is necessary to establish the new LSP and test it, and because the traffic must not be interrupted, make-before-break must be used.
在一个更复杂的用例中，可以监控LSP的许多属性，例如延迟和抖动。当LSP下降到阈值以下时，业务可以移动到提供所需（或至少更好）服务质量的另一LSP。为了实现这一点，有必要建立新的LSP并对其进行测试，而且由于流量不得中断，因此必须使用先通后断的方式。
Moreover, it may be the case that no new LSP can provide the desired attributes and that a number of LSPs need to be tested so that the best can be selected. Furthermore, even when the original LSP is set up, it could be desirable to test a number of LSPs before deciding which should be used to carry the traffic.
此外，可能没有新的LSP可以提供所需的属性，并且需要测试多个LSP以便选择最佳的LSP。此外，即使设置了原始LSP，在决定应该使用哪个LSP来承载业务之前，也可能需要测试多个LSP。
Figure 17 shows the components that interact for this use case. Because multiple LSPs might exist at once, a distinct action is needed to coordinate which one carries the traffic, and this is the job of the I2RS Client acting under the control of the ABNO Controller.
图17显示了与此用例交互的组件。由于多个LSP可能同时存在，因此需要一个不同的操作来协调哪一个LSP承载流量，这是I2RS客户端在ABNO控制器控制下的工作。
The OAM Handler is responsible for initiating tests on the LSPs and for reporting the results back to the ABNO Controller. The OAM Handler can also check end-to-end connectivity test results across a multi-domain network even when each domain runs a different technology. For example, an end-to-end path might be achieved by stitching together an MPLS segment, an Ethernet/VLAN segment, another IP segment, etc.
OAM处理程序负责启动LSP上的测试，并将结果报告给ABNO控制器。OAM处理程序还可以检查跨多域网络的端到端连接测试结果，即使每个域运行不同的技术。例如，可以通过将MPLS段、以太网/VLAN段、另一IP段等缝合在一起来实现端到端路径。
Otherwise, the process is similar to that for reoptimization as discussed in Section 3.3.1.
否则，该过程与第3.3.1节中讨论的再优化过程类似。
+---------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+----------------------+----------------------+
|
+------+ +------------+------------+ +-------+
|Policy+---+ ABNO Controller +----+ OAM |
|Agent | | +--+ |Handler|
+------+ +------------+------------+ | +---+---+
| | |
+-------+-------+ +--+---+ |
| PCE | | I2RS | |
+-------+-------+ |Client| |
| +--+---+ |
| | |
+-----------------------+---------------+-----+-+
/ Network \
+---------------------------------------------------+
+---------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+----------------------+----------------------+
|
+------+ +------------+------------+ +-------+
|Policy+---+ ABNO Controller +----+ OAM |
|Agent | | +--+ |Handler|
+------+ +------------+------------+ | +---+---+
| | |
+-------+-------+ +--+---+ |
| PCE | | I2RS | |
+-------+-------+ |Client| |
| +--+---+ |
| | |
+-----------------------+---------------+-----+-+
/ Network \
+---------------------------------------------------+
Figure 17: The Make-before-Break Path Test and Selection Process
图17：先通后断路径测试和选择过程
The pseudocode that follows gives an indication of the interactions between ABNO components.
下面的伪代码表示ABNO组件之间的交互。
OSS requests quality-assured service
OSS要求有质量保证的服务
:Label1
：标签1
DoWhile not enough LSPs (ABNO Controller) Instruct PCE to compute and provision the LSP (ABNO Controller) Create the LSP (PCE) EndDo
DOW尽管没有足够的LSP（ABNO控制器）指示PCE计算并配置LSP（ABNO控制器）创建LSP（PCE）EndDo
:Label2
：标签2
DoFor each LSP (ABNO Controller) Test LSP (OAM Handler) Report results to ABNO Controller (OAM Handler) EndDo
DoFor每个LSP（ABNO控制器）测试LSP（OAM处理程序）将结果报告给ABNO控制器（OAM处理程序）EndDo
Evaluate results of all tests (ABNO Controller) Select preferred LSP and instruct I2RS Client (ABNO Controller) Put traffic on preferred LSP (I2RS Client)
评估所有测试的结果（ABNO控制器）选择首选LSP，并指示I2RS客户端（ABNO控制器）将流量置于首选LSP（I2RS客户端）上
DoWhile too many LSPs (ABNO Controller) Instruct PCE to tear down unwanted LSP (ABNO Controller) Tear down unwanted LSP (PCE) EndDo
当LSP（ABNO控制器）过多时，指示PCE拆除不需要的LSP（ABNO控制器）拆除不需要的LSP（PCE）EndDo
DoUntil trigger (OAM Handler, ABNO Controller, Policy Agent) keep sending traffic (Network) Test LSP (OAM Handler) EndDo
DoUntil触发器（OAM处理程序、ABNO控制器、策略代理）持续发送流量（网络）测试LSP（OAM处理程序）EndDo
If there is already a suitable LSP (ABNO Controller) GoTo Label2 Else GoTo Label1 EndIf
如果已经有合适的LSP（ABNO控制器），转到Label2，否则转到Label1 EndIf
Global Concurrent Optimization (GCO) is defined in [RFC5557] and represents a key technology for maximizing network efficiency by computing a set of traffic-engineered paths concurrently. A GCO path computation request will simultaneously consider the entire topology of the network, and the complete set of new LSPs together with their respective constraints. Similarly, GCO may be applied to recompute the paths of a set of existing LSPs.
[RFC5557]中定义了全局并发优化（GCO），它代表了通过同时计算一组流量工程路径来最大化网络效率的关键技术。GCO路径计算请求将同时考虑网络的整个拓扑结构以及新的LSP的完整集合以及它们各自的约束。类似地，GCO可用于重新计算一组现有lsp的路径。
GCO may be requested in a number of scenarios. These include:
在许多情况下可能会要求GCO。这些措施包括：
o Routing of new services where the PCE should consider other services or network topology.
o 路由新服务，其中PCE应考虑其他服务或网络拓扑。
o A reoptimization of existing services due to fragmented network resources or suboptimized placement of sequentially computed services.
o 由于分散的网络资源或顺序计算的服务的次优化放置，对现有服务进行重新优化。
o Recovery of connectivity for bulk services in the event of a catastrophic network failure.
o 在发生灾难性网络故障时恢复批量服务的连接。
A service provider may also want to compute and deploy new bulk services based on a predicted traffic matrix. The GCO functionality and capability to perform concurrent computation provide a significant network optimization advantage, thus utilizing network resources optimally and avoiding blocking.
服务提供商还可能希望根据预测的流量矩阵计算和部署新的批量服务。GCO的功能和执行并行计算的能力提供了显著的网络优化优势，从而优化利用网络资源并避免阻塞。
The following use case shows how the ABNO architecture and components are used to achieve concurrent optimization across a set of services.
下面的用例展示了如何使用ABNO体系结构和组件跨一组服务实现并发优化。
When considering the GCO path computation problem, we can split the GCO objective functions into three optimization categories:
在考虑GCO路径计算问题时，我们可以将GCO目标函数分为三类优化：
o Minimize aggregate Bandwidth Consumption (MBC).
o 最小化总带宽消耗（MBC）。
o Minimize the load of the Most Loaded Link (MLL).
o 最小化负载最大的链路（MLL）的负载。
o Minimize Cumulative Cost of a set of paths (MCC).
o 最小化一组路径（MCC）的累积成本。
This use case assumes that the GCO request will be offline and be initiated from an NMS/OSS; that is, it may take significant time to compute the service, and the paths reported in the response may want to be verified by the user before being provisioned within the network.
本用例假设GCO请求将脱机并从NMS/OSS启动；也就是说，计算服务可能需要相当长的时间，并且在响应中报告的路径可能希望在网络内被供应之前由用户验证。
1. Request Management
1. 请求管理
The NMS/OSS issues a request for new service connectivity for bulk services. The ABNO Controller verifies that the NMS/OSS has sufficient rights to make the service request and apply a GCO attribute with a request to Minimize aggregate Bandwidth Consumption (MBC), as shown in Figure 18.
NMS/OSS为批量服务发出新服务连接请求。ABNO控制器验证NMS/OSS是否有足够的权限发出服务请求，并在请求中应用GCO属性以最小化聚合带宽消耗（MBC），如图18所示。
+---------------------+
| NMS/OSS |
+----------+----------+
|
V
+--------+ +-----------+-------------+
| Policy +-->-+ ABNO Controller |
| Agent | | |
+--------+ +-------------------------+
+---------------------+
| NMS/OSS |
+----------+----------+
|
V
+--------+ +-----------+-------------+
| Policy +-->-+ ABNO Controller |
| Agent | | |
+--------+ +-------------------------+
Figure 18: NMS Request to ABNO Controller
图18：对ABNO控制器的NMS请求
1a. Each service request has a source, destination, and bandwidth request. These service requests are sent to the ABNO Controller and categorized as GCO requests. The PCE uses the appropriate policy for each request and consults the TED for the packet layer.
1a。每个服务请求都有一个源、目标和带宽请求。这些服务请求被发送到ABNO控制器，并归类为GCO请求。PCE对每个请求使用适当的策略，并为分组层咨询TED。
2. Service Path Computation in the Packet Layer
2. 分组层的业务路径计算
To compute a set of services for the GCO application, PCEP supports synchronization vector (SVEC) lists for synchronized dependent path computations as defined in [RFC5440] and described in [RFC6007].
为了计算GCO应用程序的一组服务，PCEP支持同步向量（SVEC）列表，用于[RFC5440]中定义和[RFC6007]中描述的同步依赖路径计算。
2a. The ABNO Controller sends the bulk service request to the GCO-capable packet-layer PCE using PCEP messaging. The PCE uses the appropriate policy for the request and consults the TED for the packet layer, as shown in Figure 19.
2a。ABNO控制器使用PCEP消息向支持GCO的数据包层PCE发送批量服务请求。PCE对请求使用适当的策略，并为数据包层咨询TED，如图19所示。
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--------+ +--+-----------+ +--------+
| | | | | |
| Policy +-->--+ GCO-Capable +---+ Packet |
| Agent | | Packet-Layer | | TED |
| | | PCE | | |
+--------+ +--------------+ +--------+
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--------+ +--+-----------+ +--------+
| | | | | |
| Policy +-->--+ GCO-Capable +---+ Packet |
| Agent | | Packet-Layer | | TED |
| | | PCE | | |
+--------+ +--------------+ +--------+
Figure 19: Path Computation Request from GCO-Capable PCE
图19：具有GCO能力的PCE的路径计算请求
2b. Upon receipt of the bulk (GCO) service requests, the PCE applies the MBC objective function and computes the services concurrently.
2b。收到批量（GCO）服务请求后，PCE应用MBC目标函数并同时计算服务。
2c. Once the requested GCO service path computation completes, the PCE sends the resulting paths back to the ABNO Controller. The response includes a fully computed explicit path for each service (TE LSP).
2c。一旦请求的GCO服务路径计算完成，PCE将结果路径发送回ABNO控制器。响应包括每个服务的完全计算的显式路径（TE LSP）。
3. The concurrently computed solution received from the PCE is sent back to the NMS/OSS by the ABNO Controller as a PCEP response, as shown in Figure 20. The NMS/OSS user can then check the candidate paths and either provision the new services or save the solution for deployment in the future.
3. ABNO控制器将从PCE接收的并行计算的解决方案作为PCEP响应发送回NMS/OSS，如图20所示。然后，NMS/OSS用户可以检查候选路径，提供新服务或保存解决方案以备将来部署。
+---------------------+
| NMS/OSS |
+----------+----------+
^
|
+----------+----------+
| ABNO Controller |
| |
+---------------------+
+---------------------+
| NMS/OSS |
+----------+----------+
^
|
+----------+----------+
| ABNO Controller |
| |
+---------------------+
Figure 20: ABNO Sends Solution to the NMS/OSS
图20:ABNO向NMS/OSS发送解决方案
The ABNO architecture provides the capability for reactive network control of resources relying on classification, profiling, and prediction based on current demands and resource utilization. Server-layer transport network resources, such as Optical Transport Network (OTN) time-slicing [G.709], or the fine granularity grid of wavelengths with variable spectral bandwidth (flexi-grid) [G.694.1], can be manipulated to meet current and projected demands in a model called Elastic Optical Networks (EON) [EON].
ABNO体系结构提供了基于当前需求和资源利用率的分类、分析和预测的资源反应式网络控制能力。服务器层传输网络资源，如光传输网络（OTN）时间切片[G.709]，或具有可变光谱带宽的波长的细粒度网格（flexi网格）[G.694.1]，可以在称为弹性光网络（EON）[EON]的模型中进行操作，以满足当前和预计的需求。
EON provides spectrum-efficient and scalable transport by introducing flexible granular traffic grooming in the optical frequency domain. This is achieved using arbitrary contiguous concatenation of the optical spectrum that allows the creation of custom-sized bandwidth. This bandwidth is defined in slots of 12.5 GHz.
EON通过在光频域中引入灵活的粒度流量疏导，提供频谱效率高且可扩展的传输。这是通过使用光谱的任意连续级联实现的，该级联允许创建自定义大小的带宽。该带宽在12.5 GHz的插槽中定义。
Adaptive Network Management (ANM) with EON allows appropriately sized optical bandwidth to be allocated to an end-to-end optical path. In flexi-grid, the allocation is performed according to the traffic volume, optical modulation format, and associated reach, or following user requests, and can be achieved in a highly spectrum-efficient and scalable manner. Similarly, OTN provides for flexible and granular provisioning of bandwidth on top of Wavelength Switched Optical Networks (WSONs).
带有EON的自适应网络管理（ANM）允许将适当大小的光带宽分配给端到端光路径。在flexi-grid中，根据业务量、光调制格式和相关的覆盖范围或后续用户请求执行分配，并且可以以高频谱效率和可伸缩的方式实现。类似地，OTN在波长交换光网络（WSON）的基础上提供了灵活和细粒度的带宽供应。
To efficiently use optical resources, a system is required that can monitor network resources and decide the optimal network configuration based on the status, bandwidth availability, and user service. We call this ANM.
为了有效利用光资源，需要一个能够监控网络资源并根据状态、带宽可用性和用户服务决定最佳网络配置的系统。我们称之为ANM。
There are different reasons to trigger an adaptive network management process; these include:
触发自适应网络管理过程有不同的原因；这些措施包括：
o Measurement: Traffic measurements can be used in order to cause spectrum allocations that fit the traffic needs as efficiently as possible. This function may be influenced by measuring the IP router traffic flows, by examining traffic engineering or link state databases, by usage thresholds for critical links in the network, or by requests from external entities. Nowadays, network operators have active monitoring probes in the network that store their results in the OSS. The OSS or OAM Handler components activate this measurement-based trigger, so the ABNO Controller would not be directly involved in this case.
o 测量：可以使用流量测量来进行频谱分配，以尽可能有效地满足流量需求。此功能可能受到以下因素的影响：测量IP路由器流量、检查流量工程或链路状态数据库、网络中关键链路的使用阈值或来自外部实体的请求。如今，网络运营商在网络中有主动监测探头，将监测结果存储在OSS中。OSS或OAM处理程序组件激活此基于度量的触发器，因此ABNO控制器不会直接参与此案例。
o Human: Operators may request ABNO to run an adaptive network planning process via an NMS.
o 人工：运营商可通过NMS请求ABNO运行自适应网络规划过程。
o Periodic: An adaptive network planning process can be run periodically to find an optimum configuration.
o 周期性：可以周期性地运行自适应网络规划过程，以找到最佳配置。
An ABNO Controller would receive a request from an OSS or NMS to run an adaptive network manager process.
ABNO控制器将接收来自OSS或NMS的请求，以运行自适应网络管理器进程。
Based on the human or periodic trigger requests described in the previous section, the OSS or NMS will send a request to the ABNO Controller to perform EON-based GCO. The ABNO Controller will select a set of services to be reoptimized and choose an objective function that will deliver the best use of network resources. In making these choices, the ABNO Controller is guided by network-wide policy on the use of resources, the definition of optimization, and the level of perturbation to existing services that is tolerable.
根据上一节所述的人工或定期触发请求，OSS或NMS将向ABNO控制器发送请求，以执行基于EON的GCO。ABNO控制器将选择一组要重新优化的服务，并选择一个目标函数，以实现网络资源的最佳利用。在做出这些选择时，ABNO控制器遵循网络范围内的资源使用政策、优化定义以及对现有服务的可容忍干扰水平。
This request for GCO is passed to the PCE, along the lines of the description in Section 3.4. The PCE can then consider the end-to-end paths and every channel's optimal spectrum assignment in order to satisfy traffic demands and optimize the optical spectrum consumption within the network.
GCO请求按照第3.4节中的描述传递给PCE。然后，PCE可以考虑端到端的路径和每个信道的最佳频谱分配，以满足业务需求，并优化网络内的光谱消耗。
The PCE will operate on the TED but is likely to also be stateful so that it knows which LSPs correspond to which waveband allocations on which links in the network. Once the PCE arrives at an answer, it returns a set of potential paths to the ABNO Controller, which passes them on to the NMS or OSS to supervise/select the subsequent path setup/modification process.
PCE将在TED上运行，但也可能是有状态的，以便它知道哪些LSP对应于网络中哪些链路上的哪些波段分配。一旦PCE得到答案，它会将一组潜在路径返回给ABNO控制器，后者将这些路径传递给NMS或OSS，以监督/选择后续的路径设置/修改过程。
This exchange is shown in Figure 21. Note that the figure does not show the interactions used by the OSS/NMS for establishing or modifying LSPs in the network.
此交换如图21所示。请注意，该图未显示OSS/NMS在网络中建立或修改LSP时使用的交互。
+---------------------------+
| OSS or NMS |
+-----------+---+-----------+
| ^
V |
+------+ +----------+---+----------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +----------+---+----------+
| ^
V |
+-----+---+----+
+ PCE |
+--------------+
+---------------------------+
| OSS or NMS |
+-----------+---+-----------+
| ^
V |
+------+ +----------+---+----------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +----------+---+----------+
| ^
V |
+-----+---+----+
+ PCE |
+--------------+
Figure 21: Adaptive Network Management with Human Intervention
图21：具有人工干预的自适应网络管理
Although most network operations are supervised by the operator, there are some actions that may not require supervision, like a simple modification of a modulation format in a Bit-rate Variable Transponder (BVT) (to increase the optical spectrum efficiency or reduce energy consumption). In this process, where human intervention is not required, the PCE sends the Provisioning Manager a new configuration to configure the network elements, as shown in Figure 22.
尽管大多数网络操作都由运营商监督，但也有一些操作可能不需要监督，比如简单修改比特率可变转发器（BVT）中的调制格式（以提高光谱效率或降低能耗）。在此过程中，在不需要人工干预的情况下，PCE向Provisioning Manager发送一个新配置，以配置网元，如图22所示。
+------------------------+
| OSS or NMS |
+-----------+------------+
|
V
+------+ +----------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +----------+------------+
|
V
+------+------+
+ PCE |
+------+------+
|
V
+----------------------------------+
| Provisioning Manager |
+----------------------------------+
+------------------------+
| OSS or NMS |
+-----------+------------+
|
V
+------+ +----------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +----------+------------+
|
V
+------+------+
+ PCE |
+------+------+
|
V
+----------------------------------+
| Provisioning Manager |
+----------------------------------+
Figure 22: Adaptive Network Management without Human Intervention
图22：无需人工干预的自适应网络管理
Pseudowires in an MPLS network [RFC3985] operate as a form of layered network over the connectivity provided by the MPLS network. The pseudowires are carried by LSPs operating as transport tunnels, and planning is necessary to determine how those tunnels are placed in the network and which tunnels are used by any pseudowire.
MPLS网络[RFC3985]中的伪线在MPLS网络提供的连接上作为分层网络的形式运行。伪线由作为传输隧道运行的LSP承载，需要进行规划以确定这些隧道在网络中的放置方式以及任何伪线使用的隧道。
This section considers four use cases: multi-segment pseudowires, path-diverse pseudowires, path-diverse multi-segment pseudowires, and pseudowire segment protection. Section 3.6.5 describes the applicability of the ABNO architecture to these four use cases.
本节讨论四种使用情形：多段伪线、路径多样性伪线、路径多样性多段伪线和伪线段保护。第3.6.5节描述了ABNO体系结构对这四个用例的适用性。
[RFC5254] describes the architecture for multi-segment pseudowires. An end-to-end service, as shown in Figure 23, can consist of a series of stitched segments shown in the figure as AC, PW1, PW2, PW3, and AC. Each pseudowire segment is stitched at a "stitching Provider Edge" (S-PE): for example, PW1 is stitched to PW2 at S-PE1. Each access circuit (AC) is stitched to a pseudowire segment at a "terminating PE" (T-PE): for example, PW1 is stitched to the AC at T-PE1.
[RFC5254]描述了多段伪导线的体系结构。如图23所示，端到端服务可以由图中所示的一系列缝合段组成，如AC、PW1、PW2、PW3和AC。每个伪线段在“缝合提供者边缘”（S-PE）处缝合：例如，PW1在S-PE1处缝合到PW2。每个接入电路（AC）缝合到“终端PE”（T-PE）处的假导线段：例如，PW1缝合到T-PE1处的AC。
Each pseudowire segment is carried across the MPLS network in an LSP operating as a transport tunnel: for example, PW1 is carried in LSP1. The LSPs between PE nodes may traverse different MPLS networks with the PEs as border nodes, or the PEs may lie within the network such that each LSP spans only part of the network.
每个伪线段在作为传输隧道运行的LSP中跨MPLS网络传输：例如，PW1在LSP1中传输。PE节点之间的LSP可以以PEs作为边界节点穿越不同的MPLS网络，或者PEs可以位于网络内，使得每个LSP仅跨越网络的一部分。
----- ----- ----- -----
--- |T-PE1| LSP1 |S-PE1| LSP2 |S-PE3| LSP3 |T-PE2| +---+
| | AC | |=======| |=======| |=======| | AC | |
|CE1|----|........PW1........|..PW2........|..PW3........|----|CE2|
| | | |=======| |=======| |=======| | | |
--- | | | | | | | | +---+
----- ----- ----- -----
----- ----- ----- -----
--- |T-PE1| LSP1 |S-PE1| LSP2 |S-PE3| LSP3 |T-PE2| +---+
| | AC | |=======| |=======| |=======| | AC | |
|CE1|----|........PW1........|..PW2........|..PW3........|----|CE2|
| | | |=======| |=======| |=======| | | |
--- | | | | | | | | +---+
----- ----- ----- -----
Figure 23: Multi-Segment Pseudowire
图23：多段伪导线
While the topology shown in Figure 23 is easy to navigate, the reality of a deployed network can be considerably more complex. The topology in Figure 24 shows a small mesh of PEs. The links between the PEs are not physical links but represent the potential of MPLS LSPs between the PEs.
虽然图23所示的拓扑结构易于导航，但部署网络的实际情况可能要复杂得多。图24中的拓扑显示了PEs的一个小网格。PEs之间的链路不是物理链路，而是表示PEs之间MPLS LSP的潜力。
When establishing the end-to-end service between Customer Edge nodes (CEs) CE1 and CE2, some choice must be made about which PEs to use. In other words, a path computation must be made to determine the pseudowire segment "hops", and then the necessary LSP tunnels must be established to carry the pseudowire segments that will be stitched together.
在客户边缘节点（CE）CE1和CE2之间建立端到端服务时，必须选择要使用的PE。换句话说，必须进行路径计算以确定伪线段“跳数”，然后必须建立必要的LSP隧道以承载将缝合在一起的伪线段。
Of course, each LSP may itself require a path computation decision to route it through the MPLS network between PEs.
当然，每个LSP本身可能需要一个路径计算决策来通过PEs之间的MPLS网络路由它。
The choice of path for the multi-segment pseudowire will depend on such issues as:
多段伪导线路径的选择将取决于以下问题：
- MPLS connectivity
- MPLS连接
- MPLS bandwidth availability
- MPLS带宽可用性
- pseudowire stitching capability and capacity at PEs
- PEs的假线缝合能力和容量
- policy and confidentiality considerations for use of PEs
- PEs使用的政策和保密注意事项
-----
|S-PE5|
/-----\
--- ----- -----/ \----- ----- ---
|CE1|----|T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|----|CE2|
--- -----\ -----\ ----- /----- ---
\ | ------- | /
\ ----- \----- /
-----|S-PE2|-------|S-PE4|-----
----- -----
-----
|S-PE5|
/-----\
--- ----- -----/ \----- ----- ---
|CE1|----|T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|----|CE2|
--- -----\ -----\ ----- /----- ---
\ | ------- | /
\ ----- \----- /
-----|S-PE2|-------|S-PE4|-----
----- -----
Figure 24: Multi-Segment Pseudowire Network Topology
图24：多段伪线网络拓扑
The connectivity service provided by a pseudowire may need to be resilient to failure. In many cases, this function is provided by provisioning a pair of pseudowires carried by path-diverse LSPs across the network, as shown in Figure 25 (the terminology is inherited directly from [RFC3985]). Clearly, in this case, the challenge is to keep the two LSPs (LSP1 and LSP2) disjoint within the MPLS network. This problem is not different from the normal MPLS path-diversity problem.
伪线提供的连接服务可能需要具有故障恢复能力。在许多情况下，此功能是通过在网络上提供一对由路径不同的LSP承载的伪线来实现的，如图25所示（术语直接继承自[RFC3985]）。显然，在这种情况下，挑战在于在MPLS网络中保持两个LSP（LSP1和LSP2）不相交。这个问题与一般的MPLS路径分集问题没有什么不同。
------- -------
| PE1 | LSP1 | PE2 |
AC | |=======================| | AC
----...................PW1...................----
--- - / | |=======================| | \ -----
| |/ | | | | \| |
| CE1 + | | MPLS Network | | + CE2 |
| |\ | | | | /| |
--- - \ | |=======================| | / -----
----...................PW2...................----
AC | |=======================| | AC
| | LSP2 | |
------- -------
------- -------
| PE1 | LSP1 | PE2 |
AC | |=======================| | AC
----...................PW1...................----
--- - / | |=======================| | \ -----
| |/ | | | | \| |
| CE1 + | | MPLS Network | | + CE2 |
| |\ | | | | /| |
--- - \ | |=======================| | / -----
----...................PW2...................----
AC | |=======================| | AC
| | LSP2 | |
------- -------
Figure 25: Path-Diverse Pseudowires
图25：不同路径的伪导线
The path-diverse pseudowire is developed in Figure 26 by the "dual-homing" of each CE through more than one PE. The requirement for LSP path diversity is exactly the same, but it is complicated by the LSPs having distinct end points. In this case, the head-end router (e.g., PE1) cannot be relied upon to maintain the path diversity through the signaling protocol because it is aware of the path of only one of the LSPs. Thus, some form of coordinated path computation approach is needed.
路径多样性伪线在图26中通过每个CE通过多个PE的“双归巢”形成。对LSP路径分集的要求是完全相同的，但由于LSP具有不同的端点，因此要求非常复杂。在这种情况下，不能依靠头端路由器（例如，PE1）通过信令协议来维持路径多样性，因为它只知道一个lsp的路径。因此，需要某种形式的协调路径计算方法。
------- -------
| PE1 | LSP1 | PE2 |
AC | |=======================| | AC
---...................PW1...................---
/ | |=======================| | \
----- / | | | | \ -----
| |/ ------- ------- \| |
| CE1 + MPLS Network + CE2 |
| |\ ------- ------- /| |
----- \ | PE3 | | PE4 | / -----
\ | |=======================| | /
---...................PW2...................---
AC | |=======================| | AC
| | LSP2 | |
------- -------
------- -------
| PE1 | LSP1 | PE2 |
AC | |=======================| | AC
---...................PW1...................---
/ | |=======================| | \
----- / | | | | \ -----
| |/ ------- ------- \| |
| CE1 + MPLS Network + CE2 |
| |\ ------- ------- /| |
----- \ | PE3 | | PE4 | / -----
\ | |=======================| | /
---...................PW2...................---
AC | |=======================| | AC
| | LSP2 | |
------- -------
Figure 26: Path-Diverse Pseudowires with Disjoint PEs
图26：具有不相交PEs的路径多样性伪线
Figure 27 shows how the services in the previous two sections may be combined to offer end-to-end diverse paths in a multi-segment environment. To offer end-to-end resilience to failure, two entirely diverse, end-to-end multi-segment pseudowires may be needed.
图27显示了如何组合前两部分中的服务，以在多段环境中提供端到端的不同路径。为了提供端到端的故障恢复能力，可能需要两条完全不同的端到端多段伪导线。
----- -----
|S-PE5|--------------|T-PE4|
/-----\ ----- \
----- -----/ \----- ----- \ ---
|T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|--|CE2|
--- / -----\ -----\ ----- /----- ---
|CE1|< ------- | ------- | /
--- \ ----- \----- \----- /
|T-PE3|-------|S-PE2|-------|S-PE4|-----
----- ----- -----
----- -----
|S-PE5|--------------|T-PE4|
/-----\ ----- \
----- -----/ \----- ----- \ ---
|T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|--|CE2|
--- / -----\ -----\ ----- /----- ---
|CE1|< ------- | ------- | /
--- \ ----- \----- \----- /
|T-PE3|-------|S-PE2|-------|S-PE4|-----
----- ----- -----
Figure 27: Path-Diverse Multi-Segment Pseudowire Network Topology
图27：路径多样性多段伪线网络拓扑
Just as in any diverse-path computation, the selection of the first path needs to be made with awareness of the fact that a second, fully diverse path is also needed. If a sequential computation was applied to the topology in Figure 27, the first path CE1,T-PE1,S-PE1, S-PE3,T-PE2,CE2 would make it impossible to find a second path that was fully diverse from the first.
正如在任何多样性路径计算中一样，选择第一条路径时需要意识到还需要第二条完全多样性的路径。如果对图27中的拓扑应用顺序计算，则第一条路径CE1、T-PE1、S-PE1、S-PE3、T-PE2、CE2将无法找到与第一条完全不同的第二条路径。
But the problem is complicated by the multi-layer nature of the network. It is not enough that the PEs are chosen to be diverse because the LSP tunnels between them might share links within the MPLS network. Thus, a multi-layer planning solution is needed to achieve the desired level of service.
但由于网络的多层性，问题变得复杂。选择多样化的PEs是不够的，因为它们之间的LSP隧道可能在MPLS网络内共享链路。因此，需要一个多层规划解决方案来实现所需的服务级别。
An alternative to the end-to-end pseudowire protection service enabled by the mechanism described in Section 3.6.3 can be achieved by protecting individual pseudowire segments or PEs. For example, in Figure 27, the pseudowire between S-PE1 and S-PE5 may be protected by a pair of stitched segments running between S-PE1 and S-PE5, and between S-PE5 and S-PE3. This is shown in detail in Figure 28.
第3.6.3节所述机制启用的端到端伪线保护服务的替代方案可通过保护单个伪线段或PEs实现。例如，在图27中，S-PE1和S-PE5之间的伪线可由一对在S-PE1和S-PE5之间以及在S-PE5和S-PE3之间运行的缝合段保护。图28详细显示了这一点。
------- ------- -------
| S-PE1 | LSP1 | S-PE5 | LSP3 | S-PE3 |
| |============| |============| |
| .........PW1..................PW3.......... | Outgoing
Incoming | : |============| |============| : | Segment
Segment | : | ------- | :..........
...........: | | : |
| : | | : |
| : |=================================| : |
| .........PW2............................... |
| |=================================| |
| | LSP2 | |
------- -------
------- ------- -------
| S-PE1 | LSP1 | S-PE5 | LSP3 | S-PE3 |
| |============| |============| |
| .........PW1..................PW3.......... | Outgoing
Incoming | : |============| |============| : | Segment
Segment | : | ------- | :..........
...........: | | : |
| : | | : |
| : |=================================| : |
| .........PW2............................... |
| |=================================| |
| | LSP2 | |
------- -------
Figure 28: Fragment of a Segment-Protected Multi-Segment Pseudowire
图28：段保护多段伪导线的碎片
The determination of pseudowire protection segments requires coordination and planning, and just as in Section 3.6.5, this planning must be cognizant of the paths taken by LSPs through the underlying MPLS networks.
伪线保护段的确定需要协调和规划，正如第3.6.5节所述，该规划必须了解LSP通过底层MPLS网络的路径。
The ABNO architecture lends itself well to the planning and control of pseudowires in the use cases described above. The user or application needs a single point at which it requests services: the ABNO Controller. The ABNO Controller can ask a PCE to draw on the topology of pseudowire stitching-capable PEs as well as additional information regarding PE capabilities, such as load on PEs and administrative policies, and the PCE can use a series of TEDs or other PCEs for the underlying MPLS networks to determine the paths of the LSP tunnels. At the time of this writing, PCEP does not support
ABNO体系结构非常适合在上述用例中规划和控制伪线。用户或应用程序需要一个请求服务的点：ABNO控制器。ABNO控制器可以要求PCE利用支持伪线缝合的PE的拓扑以及关于PE能力的附加信息，例如PEs上的负载和管理策略，并且PCE可以为底层MPLS网络使用一系列TED或其他PCE来确定LSP隧道的路径。在撰写本文时，PCEP不支持
path computation requests and responses concerning pseudowires, but the concepts are very similar to existing uses and the necessary extensions would be very small.
关于伪线的路径计算请求和响应，但其概念与现有用途非常相似，并且所需的扩展非常小。
Once the paths have been computed, a number of different provisioning systems can be used to instantiate the LSPs and provision the pseudowires under the control of the Provisioning Manager. The ABNO Controller will use the I2RS Client to instruct the network devices about what traffic should be placed on which pseudowires and, in conjunction with the OAM Handler, can ensure that failure events are handled correctly, that service quality levels are appropriate, and that service protection levels are maintained.
一旦计算了路径，就可以使用许多不同的供应系统在供应管理器的控制下实例化LSP和供应伪线。ABNO控制器将使用I2RS客户端向网络设备指示应在哪些伪线上放置哪些通信量，并与OAM处理程序一起确保故障事件得到正确处理、服务质量级别适当以及服务保护级别得到维护。
In many respects, the pseudowire network forms an overlay network (with its own TED and provisioning mechanisms) carried by underlying packet networks. Further client networks (the pseudowire payloads) may be carried by the pseudowire network. Thus, the problem space being addressed by ABNO in this case is a classic multi-layer network.
在许多方面，伪线网络形成由底层分组网络承载的覆盖网络（具有自己的TED和供应机制）。进一步的客户端网络（伪线有效载荷）可由伪线网络承载。因此，ABNO在本例中解决的问题空间是一个经典的多层网络。
Considering the term "stratum" to broadly differentiate the layers of most concern to the application and to the network in general, the need for Cross-Stratum Optimization (CSO) arises when the application stratum and network stratum need to be coordinated to achieve operational efficiency as well as resource optimization in both application and network strata.
考虑到术语“层”可以广泛区分应用程序和网络最关心的层，因此需要跨层优化（CSO）当需要协调应用程序层和网络层以实现操作效率以及应用程序层和网络层中的资源优化时出现。
Data center-based applications can provide a wide variety of services such as video gaming, cloud computing, and grid applications. High-bandwidth video applications are also emerging, such as remote medical surgery, live concerts, and sporting events.
基于数据中心的应用程序可以提供多种服务，如视频游戏、云计算和网格应用程序。高带宽视频应用也正在兴起，如远程医疗手术、现场音乐会和体育赛事。
This use case for the ABNO architecture is mainly concerned with data center applications that make substantial bandwidth demands either in aggregate or individually. In addition, these applications may need specific bounds on QoS-related parameters such as latency and jitter.
ABNO体系结构的这个用例主要涉及数据中心应用程序，这些应用程序在总体上或单独上都需要大量带宽。此外，这些应用程序可能需要QoS相关参数（如延迟和抖动）的特定界限。
Data centers come in a wide variety of sizes and configurations, but all contain compute servers, storage, and application control. Data centers offer application services to end-users, such as video gaming, cloud computing, and others. Since the data centers used to provide application services may be distributed around a network, the decisions about the control and management of application services, such as where to instantiate another service instance or to which
数据中心有各种各样的大小和配置，但都包含计算服务器、存储和应用程序控制。数据中心为最终用户提供应用服务，如视频游戏、云计算等。由于用于提供应用程序服务的数据中心可能分布在网络周围，因此有关应用程序服务的控制和管理的决策，例如在何处实例化另一个服务实例或向何处实例化另一个服务实例
data center a new client is assigned, can have a significant impact on the state of the network. Conversely, the capabilities and state of the network can have a major impact on application performance.
数据中心如果分配了新客户机，可能会对网络状态产生重大影响。相反，网络的能力和状态会对应用程序性能产生重大影响。
These decisions are typically made by applications with very little or no information concerning the underlying network. Hence, such decisions may be suboptimal from the application's point of view or considering network resource utilization and quality of service.
这些决策通常是由应用程序在很少或根本没有关于底层网络的信息的情况下做出的。因此，从应用程序的角度或考虑网络资源利用率和服务质量的角度来看，这样的决策可能是次优的。
Cross-Stratum Optimization is the process of optimizing both the application experience and the network utilization by coordinating decisions in the application stratum and the network stratum. Application resources can be roughly categorized into computing resources (i.e., servers of various types and granularities, such as Virtual Machines (VMs), memory, and storage) and content (e.g., video, audio, databases, and large data sets). By "network stratum" we mean the IP layer and below (e.g., MPLS, Synchronous Digital Hierarchy (SDH), OTN, WDM). The network stratum has resources that include routers, switches, and links. We are particularly interested in further unleashing the potential presented by MPLS and GMPLS control planes at the lower network layers in response to the high aggregate or individual demands from the application layer.
跨层优化是通过协调应用层和网络层的决策来优化应用体验和网络利用率的过程。应用程序资源大致可分为计算资源（即各种类型和粒度的服务器，如虚拟机（VM）、内存和存储）和内容（如视频、音频、数据库和大型数据集）。“网络层”是指IP层及其以下（例如MPLS、同步数字体系（SDH）、OTN、WDM）。网络层具有包括路由器、交换机和链路的资源。我们特别感兴趣的是，在较低的网络层进一步释放MPLS和GMPLS控制平面提供的潜力，以响应来自应用层的高聚合或单个需求。
This use case demonstrates that the ABNO architecture can allow cross-stratum application/network optimization for the data center use case. Other forms of Cross-Stratum Optimization (for example, for peer-to-peer applications) are out of scope.
该用例表明ABNO体系结构可以为数据中心用例进行跨层应用程序/网络优化。其他形式的跨层优化（例如，对等应用程序）已超出范围。
A key enabler for data center cost savings, consolidation, flexibility, and application scalability has been the technology of compute virtualization provided through Virtual Machines (VMs). To the software application, a VM looks like a dedicated processor with dedicated memory and a dedicated operating system.
数据中心成本节约、整合、灵活性和应用程序可扩展性的关键促成因素是通过虚拟机（VM）提供的计算虚拟化技术。对于软件应用程序来说，虚拟机就像一个具有专用内存和专用操作系统的专用处理器。
VMs not only offer a unit of compute power but also provide an "application environment" that can be replicated, backed up, and moved. Different VM configurations may be offered that are optimized for different types of processing (e.g., memory intensive, throughput intensive).
虚拟机不仅提供一个计算能力单位，还提供一个可以复制、备份和移动的“应用程序环境”。可以提供针对不同类型的处理（例如，内存密集型、吞吐量密集型）进行优化的不同VM配置。
VMs may be moved between compute resources in a data center and could be moved between data centers. VM migration serves to balance load across data center resources and has several modes:
虚拟机可以在数据中心的计算资源之间移动，也可以在数据中心之间移动。VM迁移用于跨数据中心资源平衡负载，有几种模式：
(i) scheduled vs. dynamic;
(i) 计划与动态；
(ii) bulk vs. sequential;
（ii）批量与顺序；
(iii) point-to-point vs. point-to-multipoint
（iii）点对点与点对多点
While VM migration may solve problems of load or planned maintenance within a data center, it can also be effective to reduce network load around the data center. But the act of migrating VMs, especially between data centers, can impact the network and other services that are offered.
虽然VM迁移可以解决数据中心内的负载或计划维护问题，但它也可以有效地降低数据中心周围的网络负载。但是迁移虚拟机的行为，特别是在数据中心之间迁移虚拟机的行为，可能会影响网络和提供的其他服务。
For certain applications such as disaster recovery, bulk migration is required on the fly, which may necessitate concurrent computation and path setup dynamically.
对于某些应用程序（如灾难恢复），需要动态进行批量迁移，这可能需要动态地进行并发计算和路径设置。
Thus, application stratum operations must also take into account the situation in the network stratum, even as the application stratum actions may be driven by the status of the network stratum.
因此，应用层操作还必须考虑网络层中的情况，即使应用层操作可能由网络层的状态驱动。
Application servers may be instantiated in many data centers located in different parts of the network. When an end-user makes an application request, a decision has to be made about which data center should host the processing and storage required to meet the request. One of the major drivers for operating multiple data centers (rather than one very large data center) is so that the application will run on a machine that is closer to the end-users and thus improve the user experience by reducing network latency. However, if the network is congested or the data center is overloaded, this strategy can backfire.
应用服务器可以在位于网络不同部分的许多数据中心中实例化。当最终用户提出应用程序请求时，必须决定由哪个数据中心托管满足请求所需的处理和存储。操作多个数据中心（而不是一个非常大的数据中心）的主要驱动因素之一是，应用程序将在更接近最终用户的机器上运行，从而通过减少网络延迟来改善用户体验。但是，如果网络拥挤或数据中心过载，这种策略可能适得其反。
Thus, the key factors to be considered in choosing the server on which to instantiate a VM for an application include:
因此，在选择服务器为应用程序实例化VM时要考虑的关键因素包括：
- The utilization of the servers in the data center
- 数据中心中服务器的利用率
- The network load conditions within a data center
- 数据中心内的网络负载情况
- The network load conditions between data centers
- 数据中心之间的网络负载情况
- The network conditions between the end-user and data center
- 最终用户与数据中心之间的网络状况
Again, the choices made in the application stratum need to consider the situation in the network stratum.
再次，在应用层中做出的选择需要考虑网络层中的情况。
This section shows how the ABNO architecture is applicable to the cross-stratum data center issues described in Section 3.7.1.
本节说明ABNO体系结构如何适用于第3.7.1节所述的跨层数据中心问题。
Figure 29 shows a diagram of an example data center-based application. A carrier network provides access for an end-user through PE4. Three data centers (DC1, DC2, and DC3) are accessed through different parts of the network via PE1, PE2, and PE3.
图29显示了一个基于数据中心的示例应用程序的示意图。运营商网络通过PE4为最终用户提供访问。三个数据中心（DC1、DC2和DC3）通过PE1、PE2和PE3通过网络的不同部分进行访问。
The Application Service Coordinator receives information from the end-user about the desired services and converts this information to service requests that it passes to the ABNO Controller. The end-users may already know which data center they wish to use, or the Application Service Coordinator may be able to make this determination; otherwise, the task of selecting the data center must be performed by the ABNO Controller, and this may utilize a further database (see Section 2.3.1.8) to contain information about server loads and other data center parameters.
应用程序服务协调器接收来自最终用户的有关所需服务的信息，并将该信息转换为服务请求，然后传递给ABNO控制器。最终用户可能已经知道他们希望使用哪个数据中心，或者应用程序服务协调员可能能够做出这个决定；否则，选择数据中心的任务必须由ABNO控制器执行，这可能会利用另一个数据库（见第2.3.1.8节）来包含有关服务器负载和其他数据中心参数的信息。
The ABNO Controller examines the network resources using information gathered from the other ABNO components and uses those components to configure the network to support the end-user's needs.
ABNO控制器使用从其他ABNO组件收集的信息检查网络资源，并使用这些组件配置网络以支持最终用户的需求。
+----------+ +---------------------------------+
| End-User |--->| Application Service Coordinator |
+----------+ +---------------------------------+
| |
| v
| +-----------------+
| | ABNO Controller |
| +-----------------+
| |
| v
| +---------------------+ +--------------+
| |Other ABNO Components| | o o o DC 1 |
| +---------------------+ | \|/ |
| | ------|---O |
| v | | |
| --------------------------|-- +--------------+
| / Carrier Network PE1 | \
| / .....................O \ +--------------+
| | . | | o o o DC 2 |
| | PE4 . PE2 | | \|/ |
---------|----O........................O---|--|---O |
| . | | |
| . PE3 | +--------------+
\ .....................O /
\ | / +--------------+
--------------------------|-- | o o o DC 3 |
| | \|/ |
------|---O |
| |
+--------------+
+----------+ +---------------------------------+
| End-User |--->| Application Service Coordinator |
+----------+ +---------------------------------+
| |
| v
| +-----------------+
| | ABNO Controller |
| +-----------------+
| |
| v
| +---------------------+ +--------------+
| |Other ABNO Components| | o o o DC 1 |
| +---------------------+ | \|/ |
| | ------|---O |
| v | | |
| --------------------------|-- +--------------+
| / Carrier Network PE1 | \
| / .....................O \ +--------------+
| | . | | o o o DC 2 |
| | PE4 . PE2 | | \|/ |
---------|----O........................O---|--|---O |
| . | | |
| . PE3 | +--------------+
\ .....................O /
\ | / +--------------+
--------------------------|-- | o o o DC 3 |
| | \|/ |
------|---O |
| |
+--------------+
Figure 29: The ABNO Architecture in the Context of Cross-Stratum Optimization for Data Centers
图29：数据中心跨层优化环境下的ABNO体系结构
The ABNO Controller will need to utilize a number of components to realize the CSO functions described in Section 3.7.1.
ABNO控制器需要利用多个组件来实现第3.7.1节所述的CSO功能。
The ALTO Server provides information about topological proximity and appropriate geographical location to servers with respect to the underlying networks. This information can be used to optimize the selection of peer location, which will help reduce the path of IP traffic or can contain it within specific service providers' networks. ALTO in conjunction with the ABNO Controller and the Application Service Coordinator can address general problems such as the selection of application servers based on resource availability and usage of the underlying networks.
ALTO服务器向服务器提供关于底层网络的拓扑接近度和适当地理位置的信息。此信息可用于优化对等位置的选择，这将有助于减少IP流量的路径，或将其包含在特定服务提供商的网络中。ALTO与ABNO控制器和应用程序服务协调员一起可以解决一般问题，例如根据资源可用性和基础网络的使用情况选择应用程序服务器。
The ABNO Controller can also formulate a view of current network load from the TED and from the OAM Handler (for example, by running diagnostic tools that measure latency, jitter, and packet loss). This view obviously influences not just how paths from the end-user to the data center are provisioned but can also guide the selection of which data center should provide the service and possibly even the points of attachment to be used by the end-user and to reach the chosen data center. A view of how the PCE can fit in with CSO is provided in [CSO-PCE], on which the content of Figure 29 is based.
ABNO控制器还可以从TED和OAM处理程序（例如，通过运行测量延迟、抖动和数据包丢失的诊断工具）制定当前网络负载的视图。此视图显然不仅影响从最终用户到数据中心的路径的配置方式，而且还可以指导选择应提供服务的数据中心，甚至可能影响最终用户使用的连接点以及到达所选数据中心的连接点。[CSO-PCE]中提供了PCE如何适应CSO的视图，图29的内容基于此。
As already discussed, the combination of the ABNO Controller and the Application Service Coordinator will need to be able to select (and possibly migrate) the location of the VM that provides the service for the end-user. Since a common technique used to direct the end-user to the correct VM/server is to employ DNS redirection, an important capability of the ABNO Controller will be the ability to program the DNS servers accordingly.
如前所述，ABNO控制器和应用程序服务协调器的组合需要能够选择（并可能迁移）为最终用户提供服务的VM的位置。由于用于将最终用户定向到正确VM/服务器的常用技术是采用DNS重定向，ABNO控制器的一个重要功能将是相应地对DNS服务器进行编程的能力。
Furthermore, as already noted in other sections of this document, the ABNO Controller can coordinate the placement of traffic within the network to achieve load balancing and to provide resilience to failures. These features can be used in conjunction with the functions discussed above, to ensure that the placement of new VMs, the traffic that they generate, and the load caused by VM migration can be carried by the network and do not disrupt existing services.
此外，如本文件其他章节所述，ABNO控制器可以协调网络内的流量分配，以实现负载平衡并提供故障恢复能力。这些功能可以与上面讨论的功能结合使用，以确保新VM的放置、它们生成的流量以及VM迁移引起的负载可以由网络承载，并且不会中断现有服务。
The ABNO architecture allows use cases with joint network and application-layer optimization. In such a use case, an application is presented with an abstract network topology containing only information relevant to the application. The application computes its application-layer routing according to its application objective. The application may interact with the ABNO Controller to set up explicit LSPs to support its application-layer routing.
ABNO体系结构允许使用联合网络和应用层优化的用例。在这样一个用例中，应用程序呈现一个抽象的网络拓扑，其中只包含与应用程序相关的信息。应用程序根据其应用程序目标计算其应用程序层路由。应用程序可以与ABNO控制器交互，以建立显式LSP来支持其应用层路由。
The following steps are performed to illustrate such a use case.
执行以下步骤来说明这样的用例。
1. Application Request of Application-Layer Topology
1. 应用层拓扑的应用要求
Consider the network shown in Figure 30. The network consists of five nodes and six links.
考虑图30所示的网络。该网络由五个节点和六条链路组成。
The application, which has end points hosted at N0, N1, and N2, requests network topology so that it can compute its application-layer routing, for example, to maximize the throughput of content replication among end points at the three sites.
该应用程序的端点位于N0、N1和N2，它请求网络拓扑，以便可以计算其应用层路由，例如，最大化三个站点端点之间的内容复制吞吐量。
+----+ L0 Wt=10 BW=50 +----+
| N0 |............................| N3 |
+----+ +----+
| \ L4 |
| \ Wt=7 |
| \ BW=40 |
| \ |
L1 | +----+ |
Wt=10 | | N4 | L2 |
BW=45 | +----+ Wt=12 |
| / BW=30 |
| / L5 |
| / Wt=10 |
| / BW=45 |
+----+ +----+
| N1 |............................| N2 |
+----+ L3 Wt=15 BW=35 +----+
+----+ L0 Wt=10 BW=50 +----+
| N0 |............................| N3 |
+----+ +----+
| \ L4 |
| \ Wt=7 |
| \ BW=40 |
| \ |
L1 | +----+ |
Wt=10 | | N4 | L2 |
BW=45 | +----+ Wt=12 |
| / BW=30 |
| / L5 |
| / Wt=10 |
| / BW=45 |
+----+ +----+
| N1 |............................| N2 |
+----+ L3 Wt=15 BW=35 +----+
Figure 30: Raw Network Topology
图30：原始网络拓扑
The request arrives at the ABNO Controller, which forwards the request to the ALTO Server component. The ALTO Server consults the Policy Agent, the TED, and the PCE to return an abstract, application-layer topology.
请求到达ABNO控制器，该控制器将请求转发给ALTO服务器组件。ALTO服务器咨询策略代理、TED和PCE以返回抽象的应用层拓扑。
For example, the policy may specify that the bandwidth exposed to an application may not exceed 40 Mbps. The network has precomputed that the route from N0 to N2 should use the path N0->N3->N2, according to goals such as GCO (see Section 3.4). The ALTO Server can then produce a reduced topology for the application, such as the topology shown in Figure 31.
例如，该策略可以指定向应用公开的带宽不能超过40mbps。根据GCO等目标，网络已预先计算从N0到N2的路线应使用路径N0->N3->N2（见第3.4节）。ALTO服务器随后可以为应用程序生成简化的拓扑，如图31所示。
+----+
| N0 |............
+----+ \
| \ \
| \ \
| \ \
| | \ AL0M2
L1 | | AL4M5 \ Wt=22
Wt=10 | | Wt=17 \ BW=30
BW=40 | | BW=40 \
| | \
| / \
| / \
| / \
+----+ +----+
| N1 |........................| N2 |
+----+ L3 Wt=15 BW=35 +----+
+----+
| N0 |............
+----+ \
| \ \
| \ \
| \ \
| | \ AL0M2
L1 | | AL4M5 \ Wt=22
Wt=10 | | Wt=17 \ BW=30
BW=40 | | BW=40 \
| | \
| / \
| / \
| / \
+----+ +----+
| N1 |........................| N2 |
+----+ L3 Wt=15 BW=35 +----+
Figure 31: Reduced Graph for a Particular Application
图31：特定应用的简化图
The ALTO Server uses the topology and existing routing to compute an abstract network map consisting of three PIDs. The pair-wise bandwidth as well as shared bottlenecks will be computed from the internal network topology and reflected in cost maps.
ALTO服务器使用拓扑和现有路由计算由三个PID组成的抽象网络图。成对带宽以及共享瓶颈将根据内部网络拓扑进行计算，并反映在成本图中。
2. Application Computes Application Overlay
2. 应用程序计算应用程序覆盖
Using the abstract topology, the application computes an application-layer routing. For concreteness, the application may compute a spanning tree to maximize the total bandwidth from N0 to N2. Figure 32 shows an example of application-layer routing, using a route of N0->N1->N2 for 35 Mbps and N0->N2 for 30 Mbps, for a total of 65 Mbps.
应用程序使用抽象拓扑计算应用程序层路由。具体而言，应用程序可以计算生成树以最大化从N0到N2的总带宽。图32显示了一个应用层路由的示例，使用N0->N1->N2路由35Mbps，使用N0->N2路由30Mbps，总共65Mbps。
+----+
| N0 |----------------------------------+
+----+ AL0M2 BW=30 |
| |
| |
| |
| |
| L1 |
| |
| BW=35 |
| |
| |
| |
V V
+----+ L3 BW=35 +----+
| N1 |...............................>| N2 |
+----+ +----+
+----+
| N0 |----------------------------------+
+----+ AL0M2 BW=30 |
| |
| |
| |
| |
| L1 |
| |
| BW=35 |
| |
| |
| |
V V
+----+ L3 BW=35 +----+
| N1 |...............................>| N2 |
+----+ +----+
Figure 32: Application-Layer Spanning Tree
图32：应用层生成树
3. Application Path Set Up by the ABNO Controller
3. ABNO控制器设置的应用程序路径
The application may submit its application routes to the ABNO Controller to set up explicit LSPs to support its operation. The ABNO Controller consults the ALTO maps to map the application-layer routing back to internal network topology and then instructs the Provisioning Manager to set up the paths. The ABNO Controller may re-trigger GCO to reoptimize network traffic engineering.
应用程序可将其应用程序路由提交给ABNO控制器，以设置明确的LSP来支持其操作。ABNO控制器咨询ALTO映射，将应用层路由映射回内部网络拓扑，然后指示Provisioning Manager设置路径。ABNO控制器可重新触发GCO，以重新优化网络流量工程。
This section serves as a placeholder for other potential use cases that might get documented in future documents.
本节作为其他潜在用例的占位符，这些用例可能会在将来的文档中记录下来。
This use case could cover the following scenarios:
此用例可以涵盖以下场景：
- Nested LSPs
- 嵌套LSP
- Packet Classification (IP flows into LSPs at edge routers)
- 数据包分类（IP在边缘路由器流入LSP）
- Bucket Stuffing
- 桶填料
- IP Flows into ECMP Hash Bucket
- IP流入ECMP哈希桶
Bandwidth scheduling consists of configuring LSPs based on a given time schedule. This can be used to support maintenance or operational schedules or to adjust network capacity based on traffic pattern detection.
带宽调度包括基于给定时间调度配置LSP。这可用于支持维护或运行计划，或根据流量模式检测调整网络容量。
The ABNO framework provides the components to enable bandwidth scheduling solutions.
ABNO框架提供了支持带宽调度解决方案的组件。
The ABNO architecture described in this document is presented in terms of functional units. Each unit could be implemented separately or bundled with other units into single programs or products. Furthermore, each implemented unit or bundle could be deployed on a separate device (for example, a network server) or on a separate virtual machine (for example, in a data center), or groups of programs could be deployed on the same processor. From the point of view of the architectural model, these implementation and deployment choices are entirely unimportant.
本文档中描述的ABNO体系结构以功能单元的形式呈现。每个单元可以单独实现，也可以与其他单元捆绑到单个程序或产品中。此外，每个实现的单元或捆绑包可以部署在单独的设备（例如，网络服务器）或单独的虚拟机（例如，数据中心）上，或者程序组可以部署在同一处理器上。从体系结构模型的角度来看，这些实现和部署选择完全不重要。
Similarly, the realization of a functional component of the ABNO architecture could be supported by more than one instance of an implementation, or by different instances of different implementations that provide the same or similar function. For example, the PCE component might have multiple instantiations for sharing the processing load of a large number of computation requests, and different instances might have different algorithmic capabilities so that one instance might serve parallel computation requests for disjoint paths, while another instance might have the capability to compute optimal point-to-multipoint paths.
类似地，ABNO体系结构的功能组件的实现可以由一个实现的多个实例支持，或者由提供相同或类似功能的不同实现的不同实例支持。例如，PCE组件可能具有多个实例化，用于共享大量计算请求的处理负载，不同实例可能具有不同的算法能力，因此一个实例可能为不相交路径的并行计算请求提供服务，而另一个实例可能具有计算最佳点对多点路径的能力。
This ability to have multiple instances of ABNO components also enables resiliency within the model, since in the event of the failure of one instance of one component (because of software failure, hardware failure, or connectivity problems) other instances can take over. In some circumstances, synchronization between instances of components may be needed in order to facilitate seamless resiliency.
这种拥有ABNO组件多个实例的能力还可以实现模型内的弹性，因为在一个组件的一个实例发生故障（由于软件故障、硬件故障或连接问题）时，其他实例可以接管。在某些情况下，可能需要在组件实例之间进行同步，以促进无缝恢复。
How these features are achieved in an ABNO implementation or deployment is outside the scope of this document.
如何在ABNO实现或部署中实现这些功能超出了本文档的范围。
The ABNO architecture describes a network system, and security must play an important part.
ABNO体系结构描述了一个网络系统，安全性必须发挥重要作用。
The first consideration is that the external protocols (those shown as entering or leaving the big box in Figure 1) must be appropriately secured. This security will include authentication and authorization to control access to the different functions that the ABNO system can perform, to enable different policies based on identity, and to manage the control of the network devices.
首先要考虑的是，必须适当地保护外部协议（图1中显示为进入或离开大框的协议）。这种安全性将包括身份验证和授权，以控制对ABNO系统可以执行的不同功能的访问，启用基于身份的不同策略，以及管理对网络设备的控制。
Secondly, the internal protocols that are used between ABNO components must also have appropriate security, particularly when the components are implemented on separate network nodes.
其次，ABNO组件之间使用的内部协议也必须具有适当的安全性，特别是当组件在单独的网络节点上实现时。
Considering that the ABNO system contains a lot of data about the network, the services carried by the network, and the services delivered to customers, access to information held in the system must be carefully managed. Since such access will be largely through the external protocols, the policy-based controls enabled by authentication will be powerful. But it should also be noted that any data sent from the databases in the ABNO system can reveal details of the network and should, therefore, be considered as a candidate for encryption. Furthermore, since ABNO components can access the information stored in the database, care is required to ensure that all such components are genuine and to consider encrypting data that flows between components when they are implemented at remote nodes.
考虑到ABNO系统包含大量有关网络、网络所承载的服务以及向客户提供的服务的数据，必须仔细管理对系统中信息的访问。由于这种访问将主要通过外部协议进行，因此通过身份验证启用的基于策略的控制将非常强大。但还应注意的是，从ABNO系统中的数据库发送的任何数据都可能揭示网络的细节，因此应被视为加密的候选。此外，由于ABNO组件可以访问存储在数据库中的信息，因此需要注意确保所有这样的组件是真实的，并且考虑在远程节点实现时对组件之间流动的数据进行加密。
The conclusion is that all protocols used to realize the ABNO architecture should have rich security features.
结论是，用于实现ABNO体系结构的所有协议都应该具有丰富的安全特性。
The whole of the ABNO architecture is essentially about managing the network. In this respect, there is very little extra to say. ABNO provides a mechanism to gather and collate information about the network, reporting it to management applications, storing it for future inspection, and triggering actions according to configured policies.
ABNO体系结构的整体本质上是管理网络。在这方面，没有什么额外的说法。ABNO提供了一种机制来收集和整理有关网络的信息，将其报告给管理应用程序，存储以备将来检查，并根据配置的策略触发操作。
The ABNO system will, itself, need monitoring and management. This can be seen as falling into several categories:
ABNO系统本身需要监控和管理。这可以分为几类：
- Management of external protocols
- 外部协议的管理
- Management of internal protocols
- 内部协议的管理
- Management and monitoring of ABNO components
- ABNO组件的管理和监控
- Configuration of policy to be applied across the ABNO system
- 在ABNO系统中应用的策略配置
[BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, draft-ietf-idr-ls-distribution-10, January 2015.
[BGP-LS]Gredler，H.，Medved，J.，Previdi，S.，Farrel，A.，和S.Ray，“使用BGP的链路状态和TE信息的北向分布”，正在进行的工作，草案-ietf-idr-LS-Distribution-10，2015年1月。
[CSO-PCE] Dhody, D., Lee, Y., Contreras, LM., Gonzalez de Dios, O., and N. Ciulli, "Cross Stratum Optimization enabled Path Computation", Work in Progress, draft-dhody-pce-cso-enabled-path-computation-07, January 2015.
[CSO-PCE]Dhody，D.，Lee，Y.，Contreras，LM.，Gonzalez de Dios，O.，和N.Ciulli，“跨地层优化启用路径计算”，正在进行的工作，草稿-Dhody-PCE-CSO-enabled-Path-Computation-072015年1月。
[EON] Gerstel, O., Jinno, M., Lord, A., and S.J.B. Yoo, "Elastic optical networking: a new dawn for the optical layer?", IEEE Communications Magazine, Volume 50, Issue 2, ISSN 0163-6804, February 2012.
[EON]Gerstel，O.，Jinno，M.，Lord，A.，和S.J.B.Yoo，“弹性光网络：光层的新曙光？”，IEEE通信杂志，第50卷，第2期，ISSN 0163-6804，2012年2月。
[Flood] Project Floodlight, "Floodlight REST API", <http://www.projectfloodlight.org>.
[Flood]项目泛光灯，“泛光灯休息API”<http://www.projectfloodlight.org>.
[G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid", February 2012.
[G.694.1]ITU-T建议G.694.1，“WDM应用的频谱网格：DWDM频率网格”，2012年2月。
[G.709] ITU-T Recommendation G.709, "Interface for the optical transport network", February 2012.
[G.709]ITU-T建议G.709，“光传输网络接口”，2012年2月。
[I2RS-Arch] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", Work in Progress, draft-ietf-i2rs-architecture-09, March 2015.
[I2RS Arch]Atlas，A.，Halpern，J.，Hares，S.，Ward，D.，和T.Nadeau，“路由系统接口架构”，在建工程，草案-ietf-I2RS-Architecture-09，2015年3月。
[I2RS-PS] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Interface to the Routing System Problem Statement", Work in Progress, draft-ietf-i2rs-problem-statement-06, January 2015.
[I2RS-PS]Atlas，A.，Ed.，Nadeau，T.，Ed.，和D.Ward，“路由系统问题声明的接口”，正在进行的工作，草案-ietf-I2RS-Problem-Statement-062015年1月。
[ONF] Open Networking Foundation, "OpenFlow Switch Specification Version 1.4.0 (Wire Protocol 0x05)", October 2013.
开放网络基础，“OpenFLUE交换机规范版本1.4.0（Wire协议0x05）”，2013年10月。
[PCE-Init-LSP] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Work in Progress, draft-ietf-pce-pce-initiated-lsp-03, March 2015.
[PCE初始LSP]Crabbe，E.，Minei，I.，Sivabalan，S.，和R.Varga，“状态PCE模型中PCE启动LSP设置的PCEP扩展”，正在进行的工作，草稿-ietf-PCE-PCE-initiated-LSP-032015年3月。
[RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", Work in Progress, draft-ietf-netconf-restconf-04, January 2015.
[RESTCONF]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，正在进行的工作，草案-ietf-netconf-RESTCONF-042015年1月。
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000, <http://www.rfc-editor.org/info/rfc2748>.
[RFC2748]Durham，D.，Ed.，Boyle，J.，Cohen，R.，Herzog，S.，Rajan，R.，和A.Sastry，“COPS（公共开放政策服务）协议”，RFC 27482000年1月<http://www.rfc-editor.org/info/rfc2748>.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000, <http://www.rfc-editor.org/info/rfc2753>.
[RFC2753]Yavatkar，R.，Pendarakis，D.，和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月<http://www.rfc-editor.org/info/rfc2753>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001, <http://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，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002, <http://www.rfc-editor.org/info/rfc3292>.
[RFC3292]Doria，A.，Hellstrand，F.，Sundell，K.，和T.Worster，“通用交换机管理协议（GSMP）V3”，RFC 3292，2002年6月<http://www.rfc-editor.org/info/rfc3292>.
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002, <http://www.rfc-editor.org/info/rfc3412>.
[RFC3412]Case，J.，Harrington，D.，Presohn，R.，和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月<http://www.rfc-editor.org/info/rfc3412>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月<http://www.rfc-editor.org/info/rfc3630>.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>.
[RFC3746]Yang，L.，Dantu，R.，Anderson，T.，和R.Gopal，“转发和控制单元分离（部队）框架”，RFC 37462004年4月<http://www.rfc-editor.org/info/rfc3746>.
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.
[RFC3985]Bryant，S.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月<http://www.rfc-editor.org/info/rfc3985>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月<http://www.rfc-editor.org/info/rfc4655>.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008, <http://www.rfc-editor.org/info/rfc5150>.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 51502008年2月<http://www.rfc-editor.org/info/rfc5150>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008, <http://www.rfc-editor.org/info/rfc5212>.
[RFC5212]Shiomoto，K.，Papadimitriou，D.，Le Roux，JL.，Vigoureux，M.，和D.Brungard，“基于GMPLS的多区域和多层网络（MRN/MLN）的要求”，RFC 52122008年7月<http://www.rfc-editor.org/info/rfc5212>.
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008, <http://www.rfc-editor.org/info/rfc5254>.
[RFC5254]Bitar，N.，Ed.，Bocci，M.，Ed.，和L.Martini，Ed.，“多段伪线仿真边到边（PWE3）的要求”，RFC 5254，2008年10月<http://www.rfc-editor.org/info/rfc5254>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008, <http://www.rfc-editor.org/info/rfc5277>.
[RFC5277]Chisholm，S.和H.Trevino，“NETCONF事件通知”，RFC 5277，2008年7月<http://www.rfc-editor.org/info/rfc5277>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 53052008年10月<http://www.rfc-editor.org/info/rfc5305>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008, <http://www.rfc-editor.org/info/rfc5394>.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 53942008年12月<http://www.rfc-editor.org/info/rfc5394>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月<http://www.rfc-editor.org/info/rfc5424>.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元件（PCE）通信协议（PCEP）”，RFC 54402009年3月<http://www.rfc-editor.org/info/rfc5440>.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009, <http://www.rfc-editor.org/info/rfc5520>.
[RFC5520]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，2009年4月<http://www.rfc-editor.org/info/rfc5520>.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009, <http://www.rfc-editor.org/info/rfc5557>.
[RFC5557]Lee，Y.，Le Roux，JL.，King，D.，和E.Oki，“支持全局并行优化的路径计算元素通信协议（PCEP）要求和协议扩展”，RFC 5557，2009年7月<http://www.rfc-editor.org/info/rfc5557>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009, <http://www.rfc-editor.org/info/rfc5623>.
[RFC5623]Oki，E.，Takeda，T.，Le Roux，JL.，和A.Farrel，“基于PCE的层间MPLS和GMPLS流量工程框架”，RFC 56232009年9月<http://www.rfc-editor.org/info/rfc5623>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>.
[RFC5693]Seedorf，J.和E.Burger，“应用层流量优化（ALTO）问题陈述”，RFC 56932009年10月<http://www.rfc-editor.org/info/rfc5693>.
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.
[RFC5810]Doria，A.，Ed.，Hadi Salim，J.，Ed.，Haas，R.，Ed.，Khosravi，H.，Ed.，Wang，W.，Ed.，Dong，L.，Gopal，R.，和J.Halpern，“转发和控制元件分离（部队）协议规范”，RFC 58102010年3月<http://www.rfc-editor.org/info/rfc5810>.
[RFC6007] Nishioka, I. and D. King, "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC 6007, September 2010, <http://www.rfc-editor.org/info/rfc6007>.
[RFC6007]Nishioka，I.和D.King，“使用同步向量（SVEC）列表进行同步相关路径计算”，RFC 6007，2010年9月<http://www.rfc-editor.org/info/rfc6007>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.
[RFC6020]Bjorklund，M.，Ed.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 602020，2010年10月<http://www.rfc-editor.org/info/rfc6020>.
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011, <http://www.rfc-editor.org/info/rfc6107>.
[RFC6107]Shiomoto，K.，Ed.，和A.Farrel，Ed.“动态信号分层标签交换路径的程序”，RFC 61072011年2月<http://www.rfc-editor.org/info/rfc6107>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月<http://www.rfc-editor.org/info/rfc6120>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.“网络配置协议（NETCONF）”，RFC 62412011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6707]Niven Jenkins，B.，Le Faucheur，F.，和N.Bitar，“内容分发网络互连（CDNI）问题声明”，RFC 67072012年9月<http://www.rfc-editor.org/info/rfc6707>.
[RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, November 2012, <http://www.rfc-editor.org/info/rfc6805>.
[RFC6805]King，D.，Ed.，和A.Farrel，Ed.，“路径计算元素架构在MPLS和GMPLS域序列确定中的应用”，RFC 6805，2012年11月<http://www.rfc-editor.org/info/rfc6805>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011]Claise，B.，Ed.，Trammell，B.，Ed.，和P.Aitken，“流量信息交换的IP流量信息导出（IPFIX）协议规范”，STD 77，RFC 7011，2013年9月<http://www.rfc-editor.org/info/rfc7011>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285]Alimi，R.，Ed.，Penno，R.，Ed.，Yang，Y.，Ed.，Kiesel，S.，Previdi，S.，Roome，W.，Shalunov，S.，和R.Woundy，“应用层流量优化（ALTO）协议”，RFC 7285，2014年9月<http://www.rfc-editor.org/info/rfc7285>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, July 2014, <http://www.rfc-editor.org/info/rfc7297>.
[RFC7297]Boucadair，M.，Jacquenet，C.，和N.Wang，“IP连接配置文件（CPP）”，RFC 72972014年7月<http://www.rfc-editor.org/info/rfc7297>.
[Stateful-PCE] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-10, October 2014.
[有状态PCE]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的PCEP扩展”，正在进行的工作，草稿-ietf-PCE-Stateful-PCE-102014年10月。
[TL1] Telcorida, "Operations Application Messages - Language For Operations Application Messages", GR-831, November 1996.
[TL1]Telcorida，“操作应用程序消息-操作应用程序消息的语言”，GR-8311996年11月。
[TMF-MTOSI] TeleManagement Forum, "Multi-Technology Operations Systems Interface (MTOSI)", <https://www.tmforum.org/MTOSI/2319/home.html>.
[TMF-MTOSI]远程管理论坛，“多技术操作系统接口（MTOSI）”<https://www.tmforum.org/MTOSI/2319/home.html>.
[YANG-Rtg] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", Work in Progress, draft-ietf-netmod-routing-cfg-17, March 2015.
[YANG Rtg]Lhotka，L.和A.Lindem，“路由管理的YANG数据模型”，正在进行的工作，草稿-ietf-netmod-Routing-cfg-172015年3月。
This appendix provides a brief list of interfaces that are not yet defined at the time of this writing. Interfaces where there is a choice of existing protocols are not listed.
本附录提供了编写本文时尚未定义的接口的简要列表。可选择现有协议的接口未列出。
o An interface for adding additional information to the Traffic Engineering Database is described in Section 2.3.2.3. No protocol is currently identified for this interface, but candidates include:
o 第2.3.2.3节描述了向交通工程数据库添加附加信息的接口。目前尚未确定此接口的协议，但候选协议包括：
- The protocol developed or adopted to satisfy the requirements of I2RS [I2RS-Arch]
- 为满足I2RS[I2RS Arch]的要求而开发或采用的协议
- NETCONF [RFC6241]
- 网络配置[RFC6241]
o The protocol to be used by the Interface to the Routing System is described in Section 2.3.2.8. The I2RS working group has determined that this protocol will be based on a combination of NETCONF [RFC6241] and RESTCONF [RESTCONF] with further additions and modifications as deemed necessary to deliver the desired function. The details of the protocol are still to be determined.
o 第2.3.2.8节描述了路由系统接口使用的协议。I2RS工作组已确定，该协议将基于NETCONF[RFC6241]和RESTCONF[RESTCONF]的组合，并根据需要进行进一步的添加和修改，以实现所需的功能。协议的细节仍有待确定。
o As described in Section 2.3.2.10, the Virtual Network Topology Manager needs an interface that can be used by a PCE or the ABNO Controller to inform it that a client layer needs more virtual topology. It is possible that the protocol identified for use with I2RS will satisfy this requirement, or this could be achieved using extensions to the PCEP Notify message (PCNtf).
o 如第2.3.2.10节所述，虚拟网络拓扑管理器需要一个可供PCE或ABNO控制器使用的接口，以通知其客户端层需要更多虚拟拓扑。识别用于I2RS的协议可能会满足这一要求，或者这可以通过对PCEP通知消息（PCNtf）的扩展来实现。
o The north-bound interface from the ABNO Controller is used by the NMS, OSS, and Application Service Coordinator to request services in the network in support of applications as described in Section 2.3.2.11.
o 来自ABNO控制器的北向接口由NMS、OSS和应用程序服务协调员使用，以请求网络中的服务，以支持第2.3.2.11节所述的应用程序。
- It is possible that the protocol selected or designed to satisfy I2RS will address the requirement.
- 为满足I2RS而选择或设计的协议可能会满足该要求。
- A potential approach for this type of interface is described in [RFC7297] for a simple use case.
- [RFC7297]中描述了这种类型接口的一种潜在方法，用于一个简单的用例。
o As noted in Section 2.3.2.14, there may be layer-independent data models for offering common interfaces to control, configure, and report OAM.
o 如第2.3.2.14节所述，可能存在独立于层的数据模型，用于提供控制、配置和报告OAM的通用接口。
o As noted in Section 3.6, the ABNO model could be applied to placing multi-segment pseudowires in a network topology made up of S-PEs and MPLS tunnels. The current definition of PCEP [RFC5440] and associated extensions that are works in progress do not include all of the details to request such paths, so some work might be necessary, although the general concepts will be easily reusable. Indeed, such work may be necessary for the wider applicability of PCEs in many networking scenarios.
o 如第3.6节所述，ABNO模型可用于在由S-PEs和MPLS隧道组成的网络拓扑中放置多段伪线。PCEP[RFC5440]的当前定义和正在进行的相关扩展不包括请求此类路径的所有细节，因此可能需要进行一些工作，尽管一般概念很容易重用。事实上，为了使PCE在许多网络场景中具有更广泛的适用性，这些工作可能是必要的。
Acknowledgements
致谢
Thanks for discussions and review are due to Ken Gray, Jan Medved, Nitin Bahadur, Diego Caviglia, Joel Halpern, Brian Field, Ori Gerstel, Daniele Ceccarelli, Cyril Margaria, Jonathan Hardwick, Nico Wauters, Tom Taylor, Qin Wu, and Luis Contreras. Thanks to George Swallow for suggesting the existence of the SRLG database. Tomonori Takeda and Julien Meuric provided valuable comments as part of their Routing Directorate reviews. Tina Tsou provided comments as part of her Operational Directorate review.
感谢Ken Gray、Jan Medved、Nitin Bahadur、Diego Caviglia、Joel Halpern、Brian Field、Ori Gerstel、Daniele Ceccarelli、Cyril Margaria、Jonathan Hardwick、Nico Wauters、Tom Taylor、Qin Wu和Luis Contreras的讨论和评论。感谢George Swallow建议存在SRLG数据库。武田智诺里和朱利安·默里在董事会审查中提供了宝贵的意见。Tina Tsou提供了评论，作为其运营董事会审查的一部分。
This work received funding from the European Union's Seventh Framework Programme for research, technological development, and demonstration, through the PACE project under grant agreement number 619712 and through the IDEALIST project under grant agreement number 317999.
这项工作得到了欧盟第七个研究、技术开发和示范框架计划的资助，通过第619712号赠款协议项下的PACE项目和第317999号赠款协议项下的理想主义项目。
Contributors
贡献者
Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 United States EMail: qzhao@huawei.com
Quintin Zhao华为技术125美国马萨诸塞州纳戈尔技术园阿克顿01719电子邮件：qzhao@huawei.com
Victor Lopez Telefonica I+D EMail: vlopez@tid.es
Victor Lopez Telefonica I+D电子邮件：vlopez@tid.es
Ramon Casellas CTTC EMail: ramon.casellas@cttc.es
Ramon Casellas CTTC电子邮件：Ramon。casellas@cttc.es
Yuji Kamite NTT Communications Corporation EMail: y.kamite@ntt.com
Yuji Kamite NTT通信公司电子邮件：y。kamite@ntt.com
Yosuke Tanaka NTT Communications Corporation EMail: yosuke.tanaka@ntt.com
Yosuke Tanaka NTT通信公司电子邮件：Yosuke。tanaka@ntt.com
Young Lee Huawei Technologies EMail: leeyoung@huawei.com
Young Lee华为技术电子邮件：leeyoung@huawei.com
Y. Richard Yang Yale University EMail: yry@cs.yale.edu
Y.Richard Yang耶鲁大学电子邮件：yry@cs.yale.edu
Authors' Addresses
作者地址
Daniel King Old Dog Consulting
丹尼尔·金老狗咨询公司
EMail: daniel@olddog.co.uk
EMail: daniel@olddog.co.uk
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk