Internet Engineering Task Force (IETF) Y. Zhuang
Request for Comments: 8413 Q. Wu
Category: Informational H. Chen
ISSN: 2070-1721 Huawei
A. Farrel
Juniper Networks
July 2018
Internet Engineering Task Force (IETF) Y. Zhuang
Request for Comments: 8413 Q. Wu
Category: Informational H. Chen
ISSN: 2070-1721 Huawei
A. Farrel
Juniper Networks
July 2018
Framework for Scheduled Use of Resources
计划使用资源的框架
Abstract
摘要
Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.
流量工程（TE）资源的时间计划（TS）预订可用于为TE标签交换路径提供资源预订，以便更好地保证为客户提供服务，并在任何时间提高网络资源使用效率，包括计划未来的网络使用。本文档提供了一个框架，描述并讨论了支持TE资源预定的体系结构。本文档不描述实现此服务所需的特定协议或协议扩展。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8413.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8413.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Provisioning TE-LSPs and TE Resources . . . . . . . . . . 4
2.2. Selecting the Path of an LSP . . . . . . . . . . . . . . 4
2.3. Planning Future LSPs . . . . . . . . . . . . . . . . . . 5
2.4. Looking at Future Demands on TE Resources . . . . . . . . 6
2.4.1. Interaction between Time-Scheduled and Ad Hoc
Reservations . . . . . . . . . . . . . . . . . . . . 6
2.5. Requisite State Information . . . . . . . . . . . . . . . 7
3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 8
3.1. Where is Scheduling State Held? . . . . . . . . . . . . . 8
3.2. What State is Held? . . . . . . . . . . . . . . . . . . . 10
3.3. Enforcement of Operator Policy . . . . . . . . . . . . . 12
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 13
4.1. Service Request . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Reoptimization After TED Updates . . . . . . . . . . 14
4.2. Initialization and Recovery . . . . . . . . . . . . . . . 15
4.3. Synchronization Between PCEs . . . . . . . . . . . . . . 15
5. Multi-domain Considerations . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Informative References . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Provisioning TE-LSPs and TE Resources . . . . . . . . . . 4
2.2. Selecting the Path of an LSP . . . . . . . . . . . . . . 4
2.3. Planning Future LSPs . . . . . . . . . . . . . . . . . . 5
2.4. Looking at Future Demands on TE Resources . . . . . . . . 6
2.4.1. Interaction between Time-Scheduled and Ad Hoc
Reservations . . . . . . . . . . . . . . . . . . . . 6
2.5. Requisite State Information . . . . . . . . . . . . . . . 7
3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 8
3.1. Where is Scheduling State Held? . . . . . . . . . . . . . 8
3.2. What State is Held? . . . . . . . . . . . . . . . . . . . 10
3.3. Enforcement of Operator Policy . . . . . . . . . . . . . 12
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 13
4.1. Service Request . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Reoptimization After TED Updates . . . . . . . . . . 14
4.2. Initialization and Recovery . . . . . . . . . . . . . . . 15
4.3. Synchronization Between PCEs . . . . . . . . . . . . . . 15
5. Multi-domain Considerations . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Informative References . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Traffic Engineering Label Switched Paths (TE-LSPs) are connection-oriented tunnels in packet and non-packet networks [RFC3209] [RFC3945]. TE-LSPs may reserve network resources for use by the traffic they carry, thus providing some guarantees of service delivery and allowing a network operator to plan the use of the resources across the whole network.
流量工程标签交换路径（TE LSP）是分组和非分组网络中面向连接的隧道[RFC3209][RFC3945]。TE lsp可以保留网络资源供其承载的流量使用，从而提供服务交付的一些保证，并允许网络运营商规划整个网络中资源的使用。
In some technologies (such as wavelength switched optical networks) the resource is synonymous with the label that is switched on the path of the LSP so that it is not possible to establish an LSP that can carry traffic without assigning a physical resource to the LSP. In other technologies (such as packet switched networks), the resources assigned to an LSP are a measure of the capacity of a link that is dedicated for use by the traffic on the LSP.
在一些技术（例如波长交换光网络）中，资源与在LSP的路径上切换的标签同义，因此不可能在不向LSP分配物理资源的情况下建立能够承载业务的LSP。在其他技术（例如分组交换网络）中，分配给LSP的资源是专用于LSP上的业务使用的链路容量的度量。
In all cases, network planning consists of selecting paths for LSPs through the network so that there will be no contention for resources. LSP establishment is the act of setting up an LSP and reserving resources within the network. Network optimization or reoptimization is the process of repositioning LSPs in the network to make the unreserved network resources more useful for potential future LSPs while ensuring that the established LSPs continue to fulfill their objectives.
在所有情况下，网络规划都包括通过网络为LSP选择路径，这样就不会出现资源争用。LSP建立是建立LSP并在网络内保留资源的行为。网络优化或再优化是在网络中重新定位LSP的过程，以使未保留的网络资源对潜在的未来LSP更有用，同时确保已建立的LSP继续实现其目标。
It is often the case that it is known that an LSP will be needed at some specific time in the future. While a path for that LSP could be computed using knowledge of the currently established LSPs and the currently available resources, this does not give any degree of certainty that the necessary resources will be available when it is time to set up the new LSP. Yet, setting up the LSP ahead of the time when it is needed (which would guarantee the availability of the resources) is wasteful since the network resources could be used for some other purpose in the meantime.
通常情况下，已知在未来某个特定时间需要LSP。虽然可以使用当前建立的LSP和当前可用资源的知识来计算该LSP的路径，但这并不能保证在建立新LSP时必要的资源将可用。然而，在需要时提前设置LSP（这将保证资源的可用性）是浪费的，因为网络资源可以同时用于其他目的。
Similarly, it may be known that an LSP will no longer be needed after some future time and that it will be torn down, which will release the network resources that were assigned to it. This information can be helpful in planning how a future LSP is placed in the network.
类似地，可以知道，LSP在未来一段时间后将不再需要，它将被拆除，这将释放分配给它的网络资源。此信息有助于规划未来LSP在网络中的放置方式。
Time-Scheduled (TS) reservation of TE resources can be used to provide resource booking for TE-LSPs so as to better guarantee services for customers and to improve the efficiency of network resource usage into the future. This document provides a framework that describes the problem and discusses the architecture for the
TE资源的时间计划（TS）预订可用于为TE LSP提供资源预订，从而更好地保证为客户提供服务，并提高未来网络资源使用效率。本文档提供了一个描述问题的框架，并讨论了
scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.
TE资源的预定预订。本文档不描述实现此服务所需的特定协议或协议扩展。
TE-LSPs in existing networks are provisioned using a variety of techniques. They may be set up using RSVP-TE as a signaling protocol [RFC3209] [RFC3473]. Alternatively, they could be established by direct control of network elements such as in the Software-Defined Networking (SDN) paradigm. They could also be provisioned using the PCE Communication Protocol (PCEP) [RFC5440] as a control protocol to communicate with the network elements.
现有网络中的TE lsp使用多种技术来供应。它们可以使用RSVP-TE作为信令协议[RFC3209][RFC3473]进行设置。或者，可以通过直接控制网络元素（如软件定义的网络（SDN）范式）来建立它们。还可以使用PCE通信协议（PCEP）[RFC5440]作为与网络元件通信的控制协议来供应它们。
TE resources are reserved at the point of use. That is, the resources (wavelengths, timeslots, bandwidth, etc.) are reserved for use on a specific link and are tracked by the Label Switching Routers (LSRs) at the end points of the link. Those LSRs learn which resources to reserve during the LSP setup process.
TE资源在使用点保留。也就是说，资源（波长、时隙、带宽等）保留用于特定链路，并由链路端点处的标签交换路由器（lsr）跟踪。这些LSR了解在LSP设置过程中要保留哪些资源。
The use of TE resources can be varied by changing the parameters of the LSP that uses them, and the resources can be released by tearing down the LSP.
TE资源的使用可以通过改变使用它们的LSP的参数来改变，并且可以通过拆下LSP来释放资源。
Resources that have been reserved in the network for use by one LSP may be preempted for use by another LSP. If RSVP-TE signaling is in use, a holding priority and a preemption priority are used to determine which LSPs may preempt the resources that are in use for which other LSPs. If direct (central) control is in use, the controller is able to make preemption decisions. In either case, operator policy forms a key part of preemption since there is a trade between disrupting existing LSPs and enabling new LSPs.
已在网络中保留供一个LSP使用的资源可被抢占以供另一个LSP使用。如果正在使用RSVP-TE信令，则保持优先级和抢占优先级用于确定哪些lsp可以抢占正在为哪些其他lsp使用的资源。如果使用直接（中央）控制，控制器能够做出抢占决策。无论哪种情况，运营商策略都是抢占的关键部分，因为在中断现有LSP和启用新LSP之间存在权衡。
Although TE-LSPs can determine their paths hop by hop using the shortest path toward the destination to route the signaling protocol messages [RFC3209], in practice this option is not applied because it does not look far enough ahead into the network to verify that the desired resources are available. Instead, the full length of the path of an LSP is usually computed ahead of time either by the head-end LSR of a signaled LSP or by Path Computation Element (PCE) functionality that is in a dedicated server or built into network management software [RFC4655].
尽管TE LSP可以使用通向目的地的最短路径逐跳确定其路径，以路由信令协议消息[RFC3209]，但实际上，此选项不适用，因为它没有向前看足够远的网络以验证所需资源是否可用。相反，LSP路径的全长通常提前通过信号LSP的前端LSR或专用服务器中或内置于网络管理软件中的路径计算元件（PCE）功能进行计算[RFC4655]。
Such full-path computation is applied in order that an end-to-end view of the available resources in the network can be used to determine the best likelihood of establishing a viable LSP that meets the service requirements. Even in this situation, however, it is possible that two LSPs being set up at the same time will compete for scarce network resources, which means that one or both of them will fail to be established. This situation is avoided by using a centralized PCE that is aware of the LSP setup requests that are in progress.
应用这种全路径计算，以便可以使用网络中可用资源的端到端视图来确定建立满足服务需求的可行LSP的最佳可能性。然而，即使在这种情况下，同时建立的两个LSP也可能会争夺稀缺的网络资源，这意味着其中一个或两个LSP将无法建立。通过使用能够识别正在进行的LSP设置请求的集中式PCE，可以避免这种情况。
Path selection may make allowance for preemption as described in Section 2.1. That is, when selecting a path, the decision may be made to choose a path that will result in the preemption of an existing LSP. The trade-off between selecting a less optimal path, failing to select any path at all, and preempting an existing LSP must be subject to operator policy.
路径选择可考虑第2.1节所述的优先权。也就是说，当选择路径时，可以做出选择将导致现有LSP的抢占的路径的决定。选择不太理想的路径、根本无法选择任何路径和抢占现有LSP之间的权衡必须遵守运营商的政策。
Path computation is subject to "objective functions" that define what criteria are to be met when the LSP is placed [RFC4655]. These can be criteria that apply to the LSP itself (such as the shortest path to the destination) or to the network state after the LSP is set up (such as the maximized residual link bandwidth). The objective functions may be requested by the application requesting the LSP and may be filtered and enhanced by the computation engine according to operator policy.
路径计算受“目标函数”的约束，目标函数定义了放置LSP时要满足的标准[RFC4655]。这些标准可以应用于LSP本身（例如到目的地的最短路径）或LSP设置后的网络状态（例如最大化的剩余链路带宽）。目标函数可由请求LSP的应用程序请求，并可由计算引擎根据操作员策略进行过滤和增强。
LSPs may be established "on demand" when the requester determines that a new LSP is needed. In this case, the path of the LSP is computed as described in Section 2.2.
当请求者确定需要新的LSP时，可以“按需”建立LSP。在这种情况下，按照第2.2节所述计算LSP的路径。
However, in many situations, the requester knows in advance that an LSP will be needed at a particular time in the future. For example, the requester may be aware of a large traffic flow that will start at a well-known time, perhaps for a database synchronization or for the exchange of content between streaming sites. Furthermore, the requester may also know for how long the LSP is required before it can be torn down.
然而，在许多情况下，请求者预先知道在未来的特定时间将需要LSP。例如，请求者可能知道将在众所周知的时间开始的大流量，可能用于数据库同步或用于流站点之间的内容交换。此外，请求者还可能知道LSP需要多长时间才能被拆除。
The set of requests for future LSPs could be collected and held in a central database (such as at a Network Management System (NMS)): when the time comes for each LSP to be set up, the NMS can ask the PCE to compute a path and can then request the LSP to be provisioned. This approach has a number of drawbacks because it is not possible to determine in advance whether it will be possible to deliver the LSP since the resources it needs might be used by other LSPs in the
未来LSP的请求集可以收集并保存在中央数据库（例如在网络管理系统（NMS））中：当每个LSP都要设置时，NMS可以要求PCE计算路径，然后可以请求配置LSP。这种方法有许多缺点，因为不可能预先确定是否可以交付LSP，因为它所需的资源可能会被系统中的其他LSP使用
network. Thus, at the time the requester asks for the future LSP, the NMS can only make a best-effort guarantee that the LSP will be set up at the desired time.
网络因此，在请求者请求未来LSP时，NMS只能尽最大努力保证LSP将在所需时间建立。
A better solution, therefore, is for the requests for future LSPs to be serviced at once. The paths of the LSPs can be computed ahead of time and converted into reservations of network resources during specific windows in the future. That is, while the path of the LSP is computed and the network resources are reserved, the LSP is not established in the network until the time for which it is scheduled.
因此，一个更好的解决方案是对未来LSP的请求立即进行服务。LSP的路径可以提前计算，并在将来的特定窗口期间转换为网络资源的保留。也就是说，虽然LSP的路径被计算并且网络资源被保留，但是LSP直到被调度的时间才在网络中建立。
There is a need to take into account items that need to be subject to operator policy, such as 1) the amount of capacity available for scheduling future reservations, 2) the operator preference for the measures that are used with respect to the use of scheduled resources during rapid changes in traffic demand events, or 3) a complex (multiple nodes/links) failure event so as to protect against network destabilization. Operator policy is discussed further in Section 3.3.
需要考虑需要遵守运营商政策的项目，例如1）可用于安排未来预订的容量，2）运营商对在交通需求事件快速变化期间使用计划资源的措施的偏好，或3）复杂（多个节点/链路）故障事件，以防止网络不稳定。第3.3节将进一步讨论运营商政策。
While path computation, as described in Section 2.2, takes account of the currently available network resources and can act to place LSPs in the network so that there is the best possibility of future LSPs being accommodated, it cannot handle all eventualities. It is simple to construct scenarios where LSPs that are placed one at a time lead to future LSPs being blocked, but where foreknowledge of all of the LSPs would have made it possible for them all to be set up.
如第2.2节所述，虽然路径计算考虑了当前可用的网络资源，并可将LSP放置在网络中，以使未来LSP的容纳可能性最大，但它无法处理所有可能发生的情况。构建这样的场景很简单：一次放置一个LSP会导致将来的LSP被阻塞，但如果预先知道所有LSP，则可以设置所有LSP。
If, therefore, we were able to know in advance what LSPs were going to be requested, we could plan for them and ensure resources were available. Furthermore, such an approach enables a commitment to be made to a service user that an LSP will be set up and available at a specific time.
因此，如果我们能够提前知道将要申请什么样的LSP，我们就可以为它们制定计划并确保资源可用。此外，这种方法使得能够向服务用户作出承诺，即LSP将在特定时间建立并可用。
A reservation service can be achieved by tracking the current use of network resources and also having a future view of the resource usage. We call this Time-Scheduled TE (TS-TE) resource reservation.
预订服务可以通过跟踪网络资源的当前使用情况以及对资源使用情况的未来视图来实现。我们称之为定时TE（TS-TE）资源预留。
There will, of course, be a mixture of resource uses in a network. For example, normal unplanned LSPs may be requested alongside TS-TE LSPs. When an unplanned LSP is requested, no prior accommodation can be made to arrange resource availability, so the LSP can be placed no better than would be the case without TS-TE. However, the new LSP can be placed considering the future demands of TS-TE LSPs that have
当然，在一个网络中，资源的使用是混合的。例如，正常的计划外LSP可能与TS-TE LSP一起请求。当请求计划外的LSP时，无法事先安排资源可用性，因此LSP的放置不会比没有TS-TE的情况更好。然而，考虑到TS-TE LSP的未来需求，可以放置新LSP
already been requested. Of course, the unplanned LSP has no known end time and so any network planning must assume that it will consume resources forever.
已经被要求了。当然，计划外LSP没有已知的结束时间，因此任何网络规划都必须假设它将永远消耗资源。
In order to achieve the TS-TE resource reservation, the use of resources on the path needs to be scheduled. The scheduling state is used to indicate when resources are reserved and when they are available for use.
为了实现TS-TE资源预留，需要对路径上的资源使用进行调度。调度状态用于指示何时保留资源以及资源何时可供使用。
A simple information model for one piece of the scheduling state is as follows:
一个调度状态的简单信息模型如下所示：
{
link id;
resource id or reserved capacity;
reservation start time;
reservation end time
}
{
link id;
resource id or reserved capacity;
reservation start time;
reservation end time
}
The resource that is scheduled could be link capacity, physical resources on a link, buffers on an interface, etc., and could include advanced considerations such as CPU utilization and the availability of memory at nodes within the network. The resource-related information might also include the maximal unreserved bandwidth of the link over a time interval. That is, the intention is to book (reserve) a percentage of the residual (unreserved) bandwidth of the link. This could be used, for example, to reserve bandwidth for a particular class of traffic (such as IP) that doesn't have a provisioned LSP.
所调度的资源可以是链路容量、链路上的物理资源、接口上的缓冲区等，并且可以包括诸如CPU利用率和网络内节点的内存可用性等高级考虑因素。资源相关信息还可以包括链路在一个时间间隔内的最大未保留带宽。也就是说，目的是预定（保留）链路剩余（未保留）带宽的百分比。例如，这可以用于为没有配置LSP的特定流量类别（如IP）保留带宽。
For any one resource, there could be multiple pieces of the scheduling state, and for any one link, the timing windows might overlap.
对于任何一个资源，可能有多个调度状态，对于任何一个链接，计时窗口可能重叠。
There are multiple ways to realize this information model and different ways to store the data. The resource state could be expressed as a start time and an end time (as shown above), or it could be expressed as a start time and a duration. Multiple reservation periods, possibly of different lengths, may need to be recorded for each resource. Furthermore, the current state of network reservation could be kept separate from the scheduled usage, or everything could be merged into a single TS database.
实现此信息模型的方法有多种，存储数据的方法也有多种。资源状态可以表示为开始时间和结束时间（如上所示），也可以表示为开始时间和持续时间。可能需要为每个资源记录多个保留期（可能长度不同）。此外，可以将网络预订的当前状态与计划使用情况分开，或者将所有内容合并到单个TS数据库中。
An application may make a reservation request for immediate resource usage or to book resources for future use so as to maximize the chance of services being delivered and to avoid contention for
应用程序可以提出立即使用资源的预订请求，或者预订资源以备将来使用，从而最大限度地提高服务交付的机会，并避免服务争用
resources in the future. A single reservation request may book resources for multiple periods and might request a reservation that repeats on a regular cycle.
未来的资源。单个预订请求可能会预订多个时段的资源，并且可能会请求定期重复的预订。
A computation engine (that is, a PCE) may use the scheduling state information to help optimize the use of resources into the future and reduce contention or blocking when the resources are actually needed.
计算引擎（即，PCE）可以使用调度状态信息来帮助优化将来对资源的使用，并在实际需要资源时减少争用或阻塞。
Note that it is also necessary to store the information about future LSPs as distinct from the specific resource scheduling. This information is held to allow the LSPs to be instantiated when they are due, and use the paths/resources that have been computed for them, and also to provide correlation with the TS-TE resource reservations so that it is clear why resources were reserved, thus allowing preemption and handling the release of reserved resources in the event of cancellation of future LSPs. See Section 3.2 for further discussion of the distinction between scheduled resource state and scheduled LSP state.
请注意，还需要将有关未来LSP的信息存储为不同于特定资源调度的信息。保存此信息是为了允许LSP在到期时实例化，并使用为其计算的路径/资源，还为了提供与TS-TE资源保留的相关性，以便清楚地了解保留资源的原因，因此，在未来LSP取消的情况下，允许抢占和处理保留资源的释放。有关调度资源状态和调度LSP状态之间区别的进一步讨论，请参见第3.2节。
Network performance factors (such as maximum link utilization and the residual capacity of the network), with respect to supporting scheduled reservations, need to be supported and are subject to operator policy.
网络性能因素（如最大链路利用率和网络剩余容量）与支持预定预订有关，需要得到支持，并受运营商政策的约束。
This section examines several important architectural concepts to understand the design decisions reached in this document to achieve TS-TE in a scalable and robust manner.
本节将探讨几个重要的体系结构概念，以了解本文档中达成的设计决策，从而以可扩展和健壮的方式实现TS-TE。
The scheduling state information described in Section 2.5 has to be held somewhere. There are two places where this makes sense:
第2.5节中描述的调度状态信息必须保存在某处。这有两个地方是有意义的：
o in the network nodes where the resources exist; or,
o 在存在资源的网络节点中；或
o in a central scheduling controller where decisions about resource allocation are made.
o 在中央调度控制器中，对资源分配进行决策。
The first of these makes policing of resource allocation easier. It means that many points in the network can request immediate or scheduled LSPs with the associated resource reservation, and that all such requests can be correlated at the point where the resources are
第一种方法使资源分配的监管更加容易。这意味着网络中的许多点可以请求具有相关资源保留的即时或计划LSP，并且所有此类请求都可以在资源保留的点处关联
allocated. However, this approach has some scaling and technical problems:
分配。但是，这种方法存在一些扩展和技术问题：
o The most obvious issue is that each network node must retain the full time-based state for all of its resources. In a busy network with a high arrival rate of new LSPs and a low hold time for each LSP, this could be a lot of state. Network nodes are normally implemented with minimal spare memory.
o 最明显的问题是，每个网络节点必须为其所有资源保留基于时间的完整状态。在一个繁忙的网络中，新LSP的到达率很高，每个LSP的保持时间很短，这可能是很多状态。网络节点通常使用最少的备用内存来实现。
o In order that path computation can be performed, the computing entity normally known as a Path Computation Element (PCE) [RFC4655] needs access to a database of available links and nodes in the network (as well as the TE properties of said links). This database is known as the Traffic Engineering Database (TED) and is usually populated from information advertised in the IGP by each of the network nodes or exported using BGP Link State (BGP-LS) [RFC7752]. To be able to compute a path for a future LSP, the PCE needs to populate the TED with all of the future resource availability: if this information is held on the network nodes, it must also be advertised in the IGP. This could be a significant scaling issue for the IGP and the network nodes, as all of the advertised information is held at every network node and must be periodically refreshed by the IGP.
o 为了能够执行路径计算，通常称为路径计算元素（PCE）[RFC4655]的计算实体需要访问网络中可用链路和节点的数据库（以及所述链路的TE属性）。该数据库称为流量工程数据库（TED），通常由每个网络节点根据IGP中公布的信息填充，或使用BGP链路状态（BGP-LS）导出[RFC7752]。为了能够计算未来LSP的路径，PCE需要用所有未来资源可用性填充TED：如果此信息保存在网络节点上，则还必须在IGP中公布。对于IGP和网络节点来说，这可能是一个重大的扩展问题，因为所有公布的信息都保存在每个网络节点上，并且必须由IGP定期刷新。
o When a normal node restarts, it can recover the resource reservation state from the forwarding hardware, from Non-Volatile Random-Access Memory (NVRAM), or from adjacent nodes through the signaling protocol [RFC5063]. If the scheduling state is held at the network nodes, it must also be recovered after the restart of a network node. This cannot be achieved from the forwarding hardware because the reservation will not have been made, could require additional expensive NVRAM, or might require that all adjacent nodes also have the scheduling state in order to reinstall it on the restarting node. This is potentially complex processing with scaling and cost implications.
o 当正常节点重新启动时，它可以通过信令协议[RFC5063]从转发硬件、非易失性随机存取存储器（NVRAM）或相邻节点恢复资源保留状态。如果调度状态保持在网络节点上，则还必须在重新启动网络节点后恢复。这无法通过转发硬件实现，因为未进行预订，可能需要额外昂贵的NVRAM，或者可能需要所有相邻节点也具有调度状态，以便在重新启动节点上重新安装。这可能是一个复杂的处理过程，具有扩展性和成本影响。
Conversely, if the scheduling state is held centrally, it is easily available at the point of use. That is, the PCE can utilize the state to plan future LSPs and can update that stored information with the scheduled reservation of resources for those future LSPs. This approach also has several issues:
相反，如果调度状态集中保存，则在使用点很容易获得。也就是说，PCE可以利用该状态来规划未来lsp，并且可以使用针对那些未来lsp的资源的预定保留来更新所存储的信息。这种方法还有几个问题：
o If there are multiple controllers, then they must synchronize their stored scheduling state as they each plan future LSPs and they must have a mechanism to resolve resource contention. This is relatively simple and is mitigated by the fact that there is ample processing time to replan future LSPs in the case of resource contention.
o 如果有多个控制器，则它们必须同步其存储的调度状态，因为它们每个都计划未来的LSP，并且它们必须具有解决资源争用的机制。这是相对简单的，并且由于在资源争用的情况下有足够的处理时间来重新规划未来的LSP而得到缓解。
o If other sources of immediate LSPs are allowed (for example, other controllers or autonomous action by head-end LSRs), then the changes in resource availability caused by the setup or tear down of these LSPs must be reflected in the TED (by use of the IGP as is already normally done) and may have an impact on planned future LSPs. This impact can be mitigated by replanning future LSPs or through LSP preemption.
o 如果允许直接LSP的其他来源（例如，其他控制器或前端LSR的自主行动），则这些LSP的设置或拆除引起的资源可用性变化必须反映在TED中（通过使用IGP，正如通常所做的那样），并可能对计划的未来LSP产生影响。这种影响可以通过重新规划未来LSP或通过LSP抢占来缓解。
o If the scheduling state is held centrally at a PCE, the state must be held and restored after a system restart. This is relatively easy to achieve on a central server that can have access to non-volatile storage. The PCE could also synchronize the scheduling state with other PCEs after restart. See Section 4.2 for details.
o 如果调度状态在PCE集中保持，则必须在系统重新启动后保持并恢复该状态。这在可以访问非易失性存储的中央服务器上相对容易实现。重启后，PCE还可以与其他PCE同步调度状态。详见第4.2节。
o Of course, a centralized system must store information about all of the resources in the network. In a busy network with a high arrival rate of new LSPs and a low hold time for each LSP, this could be a lot of state. This is multiplied by the size of the network measured both by the number of links and nodes and by the number of trackable resources on each link or at each node. This challenge may be mitigated by the centralized server being dedicated hardware, but there remains the problem of collecting the information from the network in a timely way when there is potentially a very large amount of information to be collected and when the rate of change of that information is high. This latter challenge is only solved if the central server has full control of the booking of resources and the establishment of new LSPs so that the information from the network only serves to confirm what the central server expected.
o 当然，集中式系统必须存储有关网络中所有资源的信息。在一个繁忙的网络中，新LSP的到达率很高，每个LSP的保持时间很短，这可能是很多状态。这将乘以网络的大小（通过链路和节点的数量以及每个链路或每个节点上可跟踪资源的数量来测量）。这一挑战可以通过作为专用硬件的集中式服务器来缓解，但当可能需要收集大量信息且该信息的变化率较高时，仍然存在从网络及时收集信息的问题。只有当中央服务器完全控制资源预订和建立新的LSP，以便来自网络的信息仅用于确认中央服务器所期望的内容时，后一个挑战才得以解决。
Thus, considering these trade-offs, the architectural conclusion is that the scheduling state should be held centrally at the point of use and not in the network devices.
因此，考虑到这些权衡，架构结论是调度状态应该集中在使用点，而不是在网络设备中。
As already described, the PCE needs access to an enhanced, time-based
TED. It stores the Traffic Engineering (TE) information, such as
bandwidth, for every link for a series of time intervals. There are
a few ways to store the TE information in the TED. For example,
suppose that the amount of the unreserved bandwidth at a priority
level for a link is Bj in a time interval from time Tj to Tk (k =
j+1), where j = 0, 1, 2, ....
As already described, the PCE needs access to an enhanced, time-based
TED. It stores the Traffic Engineering (TE) information, such as
bandwidth, for every link for a series of time intervals. There are
a few ways to store the TE information in the TED. For example,
suppose that the amount of the unreserved bandwidth at a priority
level for a link is Bj in a time interval from time Tj to Tk (k =
j+1), where j = 0, 1, 2, ....
Bandwidth
^
| B3
| B1 ___________
| __________
|B0 B4
|__________ B2 _________
| ________________
|
-+-------------------------------------------------------> Time
|T0 T1 T2 T3 T4
Bandwidth
^
| B3
| B1 ___________
| __________
|B0 B4
|__________ B2 _________
| ________________
|
-+-------------------------------------------------------> Time
|T0 T1 T2 T3 T4
Figure 1: A Plot of Bandwidth Usage against Time
图1：带宽使用与时间的关系图
The unreserved bandwidth for the link can be represented and stored in the TED as [T0, B0], [T1, B1], [T2, B2], [T3, B3], ... as shown in Figure 1.
链路的无保留带宽可以表示为[T0，B0]、[T1，B1]、[T2，B2]、[T3，B3]、。。。如图1所示。
But it must be noted that service requests for future LSPs are known in terms of the LSPs whose paths are computed and for which resources are scheduled. For example, if the requester of a future LSP decides to cancel the request or to modify the request, the PCE must be able to map this to the resources that were reserved. When the LSP (or the request for the LSP with a number of time intervals) is canceled, the PCE must release the resources that were reserved on each of the links along the path of the LSP in every time interval from the TED. If the bandwidth that had been reserved for the LSP on a link was B from time T2 to T3 and the unreserved bandwidth on the link was B2 from T2 to T3, then B is added back to the link for the time interval from T2 to T3 and the unreserved bandwidth on the link from T2 to T3 will be seen to be B2 + B.
但必须注意的是，未来LSP的服务请求是根据其路径被计算并为其调度资源的LSP来确定的。例如，如果未来LSP的请求者决定取消请求或修改请求，则PCE必须能够将其映射到保留的资源。当LSP（或具有多个时间间隔的LSP请求）被取消时，PCE必须从TED释放在每个时间间隔内沿LSP路径的每个链路上保留的资源。如果为链路上的LSP保留的带宽从时间T2到T3为B，并且链路上的未保留带宽从T2到T3为B2，则在时间间隔从T2到T3时B被添加回链路，并且从T2到T3的链路上的未保留带宽将被视为B2+B。
This suggests that the PCE needs an LSP Database (LSP-DB) [RFC8231] that contains information not only about LSPs that are active in the network but also those that are planned. For each time interval that applies to the LSP, the information for an LSP stored in the LSP-DB includes: the time interval, the paths computed for the LSP satisfying the constraints in the time interval, and the resources (such as bandwidth) reserved for the LSP in the time interval. See also Section 2.3
这表明PCE需要一个LSP数据库（LSP-DB）[RFC8231]，该数据库不仅包含有关网络中活动的LSP的信息，还包含计划中的LSP的信息。对于应用于LSP的每个时间间隔，存储在LSP-DB中的LSP的信息包括：时间间隔、为满足时间间隔中的约束的LSP计算的路径以及在时间间隔中为LSP保留的资源（例如带宽）。另见第2.3节
It is an implementation choice how the TED and LSP-DB are stored both for dynamic use and for recovery after failure or restart, but it may be noted that all of the information in the scheduled TED can be recovered from the active network state and from the scheduled LSP-DB.
TED和LSP-DB的存储方式是一种实现选择，既可用于动态使用，也可用于故障或重启后的恢复，但需要注意的是，计划TED中的所有信息都可以从活动网络状态和计划LSP-DB中恢复。
Computation requests for LSPs are serviced according to operator policy. For example, a PCE may refuse a computation request because the application making the request does not have sufficient permissions or because servicing the request might take specific resource usage over a given threshold.
LSP的计算请求根据运营商策略提供服务。例如，PCE可能会拒绝计算请求，因为发出请求的应用程序没有足够的权限，或者因为服务请求可能需要超过给定阈值的特定资源使用。
Furthermore, the preemption and holding priorities of any particular computation request may be subject to the operator's policies. The request could be rejected if it does not conform to the operator's policies, or (possibly more likely) the priorities could be set/ overwritten according to the operator's policies.
此外，任何特定计算请求的抢占和持有优先级可能受制于运营商的策略。如果请求不符合运营商的策略，可能会被拒绝，或者（可能更可能）可以根据运营商的策略设置/覆盖优先级。
Additionally, the Objective Functions (OFs) of computation request (such as maximizing residual bandwidth) are also subject to operator policies. It is highly likely that the choice of OFs is not available to an application and is selected by the PCE or management system subject to operator policies and knowledge of the application.
此外，计算请求的目标函数（OFs）（如最大化剩余带宽）也受操作员策略的影响。OFs的选择很可能不适用于应用程序，而是由PCE或管理系统根据运营商政策和应用程序知识进行选择。
None of these statements is new to scheduled resources. They apply to stateless, stateful, passive, and active PCEs, and they continue to apply to scheduling of resources.
这些语句对于计划的资源来说都不是新的。它们适用于无状态、有状态、被动和主动PCE，并继续适用于资源调度。
An operator may choose to configure special behavior for a PCE that handles resource scheduling. For example, an operator might want only a certain percentage of any resource to be bookable. And an operator might want the preemption of booked resources to be an inverse function of how far in the future the resources are needed for the first time.
操作员可以选择为处理资源调度的PCE配置特殊行为。例如，操作员可能只希望任何资源中的某个百分比是可预订的。运营商可能希望预订资源的抢占权与未来首次需要资源的程度成反比。
It is a general assumption about the architecture described in Section 4 that a PCE is under the operational control of the operator that owns the resources that the PCE manipulates. Thus, the operator may configure any amount of (potentially complex) policy at the PCE. This configuration would also include policy points surrounding reoptimization of existing and planned LSPs in the event of changes in the current and future (planned) resource availability.
第4节中描述的体系结构的一般假设是，PCE处于拥有PCE所操纵资源的运营商的运营控制之下。因此，操作员可以在PCE处配置任意数量的（潜在复杂的）策略。该配置还包括在当前和未来（计划）资源可用性发生变化时，围绕现有和计划LSP重新优化的政策点。
The granularity of the timing window offered to an application will depend on an operator's policy as well as the implementation in the PCE and goes to define the operator' service offerings. Different granularities and different lengths of prebooking may be offered to different applications.
提供给应用程序的时间窗口的粒度将取决于运营商的策略以及PCE中的实现，并用于定义运营商的服务选项。针对不同的应用，可提供不同粒度和不同长度的预预订。
The architectural considerations and conclusions described in the previous section lead to the architecture described in this section and illustrated in Figure 2. The interfaces and interactions shown in the figure and labeled (a) through (f) are described in Section 4.1.
上一节中描述的体系结构考虑因素和结论导致了本节中描述的体系结构，如图2所示。第4.1节描述了图中所示并标有（a）至（f）的接口和交互。
-------------------
| Service Requester |
-------------------
^
a|
v
------- b --------
| |<--->| LSP-DB |
| | --------
| PCE |
| | c -----
| |<---->| TED |
------- -----
^ ^
| |
d| |e
| |
------+-----+--------------------
| | Network
| --------
| | Router |
v --------
----- -----
| LSR |<------>| LSR |
----- f -----
-------------------
| Service Requester |
-------------------
^
a|
v
------- b --------
| |<--->| LSP-DB |
| | --------
| PCE |
| | c -----
| |<---->| TED |
------- -----
^ ^
| |
d| |e
| |
------+-----+--------------------
| | Network
| --------
| | Router |
v --------
----- -----
| LSR |<------>| LSR |
----- f -----
Figure 2: Reference Architecture for Scheduled Use of Resources
图2：资源计划使用的参考体系结构
As shown in Figure 2, some component in the network requests a service. This may be an application, an NMS, an LSR, or any component that qualifies as a Path Computation Client (PCC). We show this on the figure as the "Service Requester", and it sends a request to the PCE for an LSP to be set up at some time (either now or in the future). The request, indicated on Figure 2 by the arrow (a), includes all of the parameters of the LSP that the requester wishes to supply, such as priority, bandwidth, start time, and end time. Note that the requester in this case may be the LSR shown in the figure or may be a distinct system.
如图2所示，网络中的某些组件请求服务。这可以是应用程序、NMS、LSR或任何符合路径计算客户端（PCC）条件的组件。我们在图中将其显示为“服务请求者”，它向PCE发送请求，要求在某个时间（现在或将来）设置LSP。图2中箭头（a）所示的请求包括请求者希望提供的LSP的所有参数，例如优先级、带宽、开始时间和结束时间。请注意，在这种情况下，请求者可能是图中所示的LSR，也可能是不同的系统。
The PCE enters the LSP request in its LSP-DB (b) and uses information from its TED (c) to compute a path that satisfies the constraints (such as bandwidth) for the LSP in the time interval from the start time to the end time. It updates the future resource availability in the TED so that further path computations can take account of the scheduled resource usage. It stores the path for the LSP into the LSP-DB (b).
PCE在其LSP-DB（b）中输入LSP请求，并使用来自其TED（c）的信息来计算在从开始时间到结束时间的时间间隔内满足LSP的约束（例如带宽）的路径。它更新TED中的未来资源可用性，以便进一步的路径计算可以考虑计划的资源使用情况。它将LSP的路径存储到LSP-DB（b）中。
When it is time (i.e., at the start time) for the LSP to be set up, the PCE sends a PCEP Initiate request to the head-end LSR (d), which provides the path to be signaled as well as other parameters, such as the bandwidth of the LSP.
当到了LSP被设置的时间（即，在开始时间），PCE向头端LSR（d）发送PCEP发起请求，该头端LSR（d）提供要发信号的路径以及其它参数，例如LSP的带宽。
As the LSP is signaled between LSRs (f), the use of resources in the network is updated and distributed using the IGP. This information is shared with the PCE either through the IGP or using BGP-LS (e), and the PCE updates the information stored in its TED (c).
当LSP在lsr（f）之间被发信号时，网络中的资源的使用被使用IGP更新和分布。该信息通过IGP或使用BGP-LS（e）与PCE共享，PCE更新其TED（c）中存储的信息。
After the LSP is set up, the head-end LSR sends a PCEP LSP State Report (PCRpt) message to the PCE (d). The report contains the resources, such as bandwidth usage, for the LSP. The PCE updates the status of the LSP in the LSP-DB according to the report.
设置LSP后，前端LSR向PCE（d）发送PCEP LSP状态报告（PCRpt）消息。该报告包含LSP的资源，例如带宽使用情况。PCE根据报告更新LSP-DB中LSP的状态。
When an LSP is no longer required (either because the Service Requester has canceled the request or because the LSP's scheduled lifetime has expired), the PCE can remove it. If the LSP is currently active, the PCE instructs the head-end LSR to tear it down (d), and the network resource usage will be updated by the IGP and advertised back to the PCE through the IGP or BGP-LS (e). Once the LSP is no longer active, the PCE can remove it from the LSP-DB (b).
当不再需要LSP时（因为服务请求者已取消请求或LSP的计划生存期已过期），PCE可以将其删除。如果LSP当前处于活动状态，则PCE指示前端LSR将其拆除（d），并且IGP将更新网络资源使用情况，并通过IGP或BGP-LS（e）将其通告回PCE。一旦LSP不再处于活动状态，PCE可以将其从LSP-DB（b）中移除。
When the TED is updated as indicated in Section 4.1, depending on operator policy (so as to minimize network perturbations), the PCE may perform reoptimization of the LSPs for which it has computed paths. These LSPs may be already provisioned, in which case the PCE issues PCEP Update request messages for the LSPs that should be adjusted. Additionally, the LSPs being reoptimized may be scheduled LSPs that have not yet been provisioned, in which case reoptimization involves updating the store of scheduled LSPs and resources.
当TED按照第4.1节所述进行更新时，根据运营商政策（以最小化网络干扰），PCE可对其已计算路径的LSP进行重新优化。这些LSP可能已经被设置，在这种情况下，PCE为LSP发出应调整的PCEP更新请求消息。另外，正在被重新优化的lsp可以是尚未被供应的调度lsp，在这种情况下，重新优化涉及更新调度lsp和资源的存储。
In all cases, the purpose of reoptimization is to take account of the resource usage and availability in the network and to compute paths for the current and future LSPs that best satisfy the objectives of those LSPs while keeping the network as clear as possible to support further LSPs. Since reoptimization may perturb established LSPs, it
在所有情况下，重新优化的目的都是考虑网络中的资源使用和可用性，并计算当前和未来LSP的路径，以最好地满足这些LSP的目标，同时保持网络尽可能清晰，以支持进一步的LSP。由于重新优化可能会干扰已建立的LSP，因此
is subject to operator oversight and policy. As the stability of the network will be impacted by frequent changes, the extent and impact of any reoptimization needs to be subject to operator policy.
受运营商监督和政策约束。由于网络的稳定性将受到频繁变化的影响，任何重新优化的程度和影响都需要遵守运营商政策。
Additionally, the status of the reserved resources (alarms) can enhance the computation and planning for future LSPs and may influence repair and reoptimization. Control of recalculations based on failures and notifications to the operator is also subject to policy.
此外，保留资源（警报）的状态可增强未来LSP的计算和规划，并可能影响修复和重新优化。根据故障和向运营商发出的通知控制重新计算也受政策约束。
See Section 3.3 for further discussion of operator policy.
有关运营商政策的进一步讨论，请参见第3.3节。
When a PCE in the architecture shown in Figure 2 is initialized, it must learn the state from the network, from its stored databases, and potentially from other PCEs in the network.
当初始化图2所示体系结构中的PCE时，它必须从网络、存储的数据库以及可能从网络中的其他PCE了解状态。
The first step is to get an accurate view of the topology and resource availability in the network. This would normally involve reading the state directly from the network via the IGP or BGP-LS (e), but it might include receiving a copy of the TED from another PCE. Note that a TED stored from a previous instantiation of the PCE is unlikely to be valid.
第一步是获得网络拓扑和资源可用性的准确视图。这通常涉及通过IGP或BGP-LS（e）直接从网络读取状态，但可能包括从另一个PCE接收TED副本。请注意，从先前PCE实例化中存储的TED不太可能有效。
Next, the PCE must construct a time-based TED to show scheduled resource usage. How it does this is implementation specific, and this document does not dictate any particular mechanism: it may recover a time-based TED previously saved to non-volatile storage, or it may reconstruct the time-based TED from information retrieved from the LSP-DB previously saved to non-volatile storage. If there is more than one PCE active in the network, the recovering PCE will need to synchronize the LSP-DB and time-based TED with other PCEs (see Section 4.3).
接下来，PCE必须构建基于时间的TED，以显示计划的资源使用情况。它是如何做到这一点的是特定于实现的，本文档没有规定任何特定的机制：它可以恢复以前保存到非易失性存储器中的基于时间的TED，或者它可以根据以前保存到非易失性存储器中的LSP-DB检索到的信息重建基于时间的TED。如果网络中有多个PCE处于活动状态，则恢复PCE需要将LSP-DB和基于时间的TED与其他PCE同步（参见第4.3节）。
Note that the stored LSP-DB needs to include the intended state and actual state of the LSPs so that when a PCE recovers, it is able to determine what actions are necessary.
请注意，存储的LSP-DB需要包括LSP的预期状态和实际状态，以便当PCE恢复时，能够确定需要采取哪些措施。
If there is active in the network more than one PCE that supports scheduling, it is important to achieve some consistency between the scheduled TED and scheduled LSP-DB held by the PCEs.
如果网络中有多个支持调度的PCE处于活动状态，则必须在PCE持有的调度TED和调度LSP-DB之间实现某种一致性。
[RFC7399] answers various questions around synchronization between the PCEs. It should be noted that the time-based "scheduled" information adds another dimension to the issue of synchronization
[RFC7399]回答了有关PCE之间同步的各种问题。应当指出，基于时间的“预定”信息为同步问题增加了另一个方面
between PCEs. It should also be noted that a deployment may use a primary PCE and then have other PCEs as backup, where a backup PCE can take over only in the event of a failure of the primary PCE. Alternatively, the PCEs may share the load at all times. The choice of the synchronization technique is largely dependent on the deployment of PCEs in the network.
在PCE之间。还应注意，部署可能使用主PCE，然后将其他PCE用作备份，其中备份PCE只能在主PCE发生故障时接管。或者，pce可以随时共享负载。同步技术的选择在很大程度上取决于PCE在网络中的部署。
One option for ensuring that multiple PCEs use the same scheduled information is simply to have the PCEs driven from the same shared database, but it is likely to be inefficient, and interoperation between multiple implementations will be harder.
确保多个PCE使用相同的计划信息的一个选项是简单地从相同的共享数据库驱动PCE，但这可能效率低下，并且多个实现之间的互操作将更加困难。
Another option is for each PCE to be responsible for its own scheduled database and to utilize some distributed database synchronization mechanism to have consistent information. Depending on the implementation, this could be efficient, but interoperation between heterogeneous implementations is still hard.
另一种选择是每个PCE负责自己的调度数据库，并利用一些分布式数据库同步机制来获得一致的信息。根据实现的不同，这可能是有效的，但异构实现之间的互操作仍然很困难。
A further approach is to utilize PCEP messages to synchronize the scheduled state between PCEs. This approach would work well if the number of PCEs that support scheduling is small, but as the number increases, considerable message exchange needs to happen to keep the scheduled databases synchronized. Future solutions could also utilize some synchronization optimization techniques for efficiency. Another variation would be to request information from other PCEs for a particular time slice, but this might have an impact on the optimization algorithm.
另一种方法是利用PCEP消息来同步pce之间的调度状态。如果支持调度的PCE数量较少，这种方法将很好地工作，但随着数量的增加，需要进行大量的消息交换以保持调度数据库的同步。未来的解决方案还可以利用一些同步优化技术来提高效率。另一种变化是从其他PCE请求特定时间段的信息，但这可能会对优化算法产生影响。
Multi-domain path computation usually requires some form of cooperation between PCEs, each of which has responsibility for determining a segment of the end-to-end path in the domain for which it has computational responsibility. When computing a scheduled path, resources need to be booked in all of the domains that the path will cross so that they are available when the LSP is finally signaled.
多域路径计算通常需要PCE之间某种形式的合作，每个PCE负责确定其负责计算的域中的端到端路径段。在计算调度路径时，需要在路径将要跨越的所有域中预订资源，以便在最终通知LSP时这些资源可用。
Per-domain path computation [RFC5152] is not an appropriate mechanism when a scheduled LSP is being computed because the computation requests at downstream PCEs are only triggered by signaling. However, a similar mechanism could be used where cooperating PCEs exchange Path Computation Request (PCReq) messages for a scheduled LSP, as shown in Figure 3. In this case, the service requester asks for a scheduled LSP that will span two domains (a). PCE1 computes a path across Domain 1 and reserves the resources and also asks PCE2 to compute and reserve in Domain 2 (b). PCE2 may return a full path or could return a path key [RFC5520]. When it is time for LSP setup,
当正在计算调度的LSP时，每域路径计算[RFC5152]不是合适的机制，因为下游pce处的计算请求仅由信令触发。然而，在协作PCE交换调度LSP的路径计算请求（PCReq）消息时，可以使用类似的机制，如图3所示。在这种情况下，服务请求者请求一个计划的LSP，该LSP将跨越两个域（a）。PCE1计算跨域1的路径并保留资源，还要求PCE2计算并保留域2（b）中的资源。PCE2可以返回完整路径，也可以返回路径键[RFC5520]。到LSP设置时间时，
PCE1 triggers the head-end LSR (c), and the LSP is signaled (d). If a path key is used, the entry LSR in Domain 2 will consult PCE2 for the path expansion (e) before completing signaling (f).
PCE1触发前端LSR（c），并向LSP发送信号（d）。如果使用路径密钥，域2中的条目LSR将在完成信令（f）之前咨询PCE2以获得路径扩展（e）。
-------------------
| Service Requester |
-------------------
^
a|
v
------ b ------
| |<---------------->| |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
-------------------
| Service Requester |
-------------------
^
a|
v
------ b ------
| |<---------------->| |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
Figure 3: Per-Domain Path Computation for Scheduled LSPs
图3：计划LSP的每个域路径计算
Another mechanism for PCE cooperation in multi-domain LSP setup is Backward Recursive PCE-Based Computation (BRPC) [RFC5441]. This approach relies on the downstream domain to supply a variety of potential paths to the upstream domain. Although BRPC can arrive at a more optimal end-to-end path than per-domain path computation, it is not well suited to LSP scheduling because the downstream PCE would need to reserve resources on all of the potential paths and then release those that the upstream PCE announced it did not plan to use.
多域LSP设置中PCE协作的另一种机制是基于PCE的反向递归计算（BRPC）[RFC5441]。这种方法依赖于下游域向上游域提供各种潜在路径。尽管BRPC可以获得比每域路径计算更优化的端到端路径，但它并不适合LSP调度，因为下游PCE需要在所有潜在路径上保留资源，然后释放上游PCE宣布不打算使用的资源。
Finally, we should consider hierarchical PCE (H-PCE) [RFC6805]. This mode of operation is similar to that shown in Figure 3, but a parent PCE is used to coordinate the requests to the child PCEs, which then results in better visibility of the end-to-end path and better coordination of the resource booking. The sequenced flow of control is shown in Figure 4.
最后，我们应该考虑分层PCE（H-PCE）[RCF6805]。此操作模式类似于图3所示，但使用父PCE来协调对子PCE的请求，这样可以更好地查看端到端路径并更好地协调资源预订。顺序控制流程如图4所示。
-------------------
| Service Requester |
-------------------
^
a|
v
--------
| |
| Parent |
| PCE |
| |
--------
^ ^ b
b| |_______________________
| |
v v
------ ------
| | | |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
-------------------
| Service Requester |
-------------------
^
a|
v
--------
| |
| Parent |
| PCE |
| |
--------
^ ^ b
b| |_______________________
| |
v v
------ ------
| | | |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
Figure 4: Hierarchical PCE for Path Computation for Scheduled LSPs
图4：用于调度LSP路径计算的分层PCE
The protocol implications of scheduled resources are unchanged from "on demand" LSP computation and setup. A discussion of securing PCEP is found in [RFC5440], and work to extend that security is provided in [RFC8253]. Furthermore, the path key mechanism described in [RFC5520] can be used to enhance privacy and security.
“按需”LSP计算和设置对调度资源的协议影响保持不变。[RFC5440]中对保护PCEP进行了讨论，并在[RFC8253]中提供了扩展该安全性的工作。此外，[RFC5520]中描述的路径密钥机制可用于增强隐私和安全性。
Similarly, there is no change to the security implications for the signaling of scheduled LSPs. A discussion of the security of the signaling protocols that would be used is found in [RFC5920].
类似地，调度lsp的信令的安全含义没有改变。[RFC5920]中对将使用的信令协议的安全性进行了讨论。
However, the use of scheduled LSPs extends the attack surface for a PCE-enabled TE system by providing a larger (logically infinite) window during which an attack can be initiated or planned. That is, if bogus scheduled LSPs can be requested and entered into the LSP-DB, then a large number of LSPs could be launched and significant network resources could be blocked. Control of scheduling requests needs to be subject to operator policy, and additional authorization needs to be applied for access to LSP scheduling. Diagnostic tools need to be provided to inspect the LSP-DB to spot attacks.
然而，计划LSP的使用通过提供一个更大的（逻辑上无限的）窗口来扩展启用PCE的TE系统的攻击面，在此期间可以发起或计划攻击。也就是说，如果可以请求虚假的计划LSP并将其输入LSP-DB，则可能会启动大量LSP，并阻塞大量网络资源。调度请求的控制需要遵守运营商政策，访问LSP调度需要应用额外的授权。需要提供诊断工具来检查LSP-DB以发现攻击。
This document has no IANA actions.
本文档没有IANA操作。
[AUTOBW] Yong, L. and Y. Lee, "ASON/GMPLS Extension for Reservation and Time Based Automatic Bandwidth Service", Work in Progress, draft-yong-ccamp-ason-gmpls-autobw-service-00, October 2006.
[AUTOBW]Yong，L.和Y.Lee，“预订和基于时间的自动带宽服务的ASON/GMPLS扩展”，正在进行的工作，草稿-Yong-ccamp-ASON-GMPLS-AUTOBW-Service-00，2006年10月。
[DRAGON] National Science Foundation, "The DRAGON Project: Dynamic Resource Allocation via GMPLS Optical Networks", Overview and Status Presentation at ONT3, September 2006, <http://www.maxgigapop.net/wp-content/uploads/ The-DRAGON-Project.pdf>.
[龙]国家科学基金会，“龙项目：通过GMPLS光网络的动态资源分配”，在Ont3，2006年9月，概述和状态呈现http://www.maxgigapop.net/wp-content/uploads/ DRAGON项目.pdf>。
[FRAMEWORK-TTS] Chen, H., Toy, M., Liu, L., and K. Pithewan, "Framework for Temporal Tunnel Services", Work In Progress, draft-chen-teas-frmwk-tts-01, March 2016.
[FRAMEWORK-TTS]Chen，H.，Toy，M.，Liu，L.，和K.Pithewan，“临时隧道服务框架”，正在进行的工作，草稿-Chen-teas-frmwk-TTS-012016年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<https://www.rfc-editor.org/info/rfc3473>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <https://www.rfc-editor.org/info/rfc3945>.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 3945，DOI 10.17487/RFC3945，2004年10月<https://www.rfc-editor.org/info/rfc3945>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<https://www.rfc-editor.org/info/rfc4655>.
[RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, <https://www.rfc-editor.org/info/rfc5063>.
[RFC5063]Satyanarayana，A.，Ed.和R.Rahman，Ed.，“GMPLS资源预留协议（RSVP）优雅重启的扩展”，RFC 5063，DOI 10.17487/RFC5063，2007年10月<https://www.rfc-editor.org/info/rfc5063>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <https://www.rfc-editor.org/info/rfc5152>.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，DOI 10.17487/RFC5152，2008年2月<https://www.rfc-editor.org/info/rfc5152>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<https://www.rfc-editor.org/info/rfc5440>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, <https://www.rfc-editor.org/info/rfc5441>.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）程序”，RFC 5441，DOI 10.17487/RFC5441，2009年4月<https://www.rfc-editor.org/info/rfc5441>.
[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, DOI 10.17487/RFC5520, April 2009, <https://www.rfc-editor.org/info/rfc5520>.
[RFC5520]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，DOI 10.17487/RFC5520，2009年4月<https://www.rfc-editor.org/info/rfc5520>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[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, DOI 10.17487/RFC6805, November 2012, <https://www.rfc-editor.org/info/rfc6805>.
[RFC6805]King，D.，Ed.和A.Farrel，Ed.，“路径计算元素架构在MPLS和GMPLS域序列确定中的应用”，RFC 6805，DOI 10.17487/RFC6805，2012年11月<https://www.rfc-editor.org/info/rfc6805>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-editor.org/info/rfc7399>.
[RFC7399]Farrel，A.和D.King，“路径计算元素架构中未回答的问题”，RFC 7399，DOI 10.17487/RFC7399，2014年10月<https://www.rfc-editor.org/info/rfc7399>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752]Gredler，H.，Ed.，Medved，J.，Previdi，S.，Farrel，A.，和S.Ray，“使用BGP的链路状态和流量工程（TE）信息的北向分布”，RFC 7752，DOI 10.17487/RFC7752，2016年3月<https://www.rfc-editor.org/info/rfc7752>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的路径计算元素通信协议（PCEP）扩展”，RFC 8231，DOI 10.17487/RFC82312017年9月<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8253]Lopez，D.，Gonzalez de Dios，O.，Wu，Q.，和D.Dhody，“PCEP：使用TLS为路径计算元素通信协议（PCEP）提供安全传输”，RFC 8253，DOI 10.17487/RFC8253，2017年10月<https://www.rfc-editor.org/info/rfc8253>.
Acknowledgements
致谢
This work has benefited from the discussions of resource scheduling over the years. In particular, the DRAGON project [DRAGON] and [AUTOBW], both of which provide approaches to auto-bandwidth services in GMPLS networks.
这项工作得益于多年来对资源调度的讨论。特别是，DRAGON项目[DRAGON]和[AUTOBW]都提供了GMPLS网络中自动带宽服务的方法。
Mehmet Toy, Lei Liu, and Khuzema Pithewan contributed to an earlier version of [FRAMEWORK-TTS]. We would like to thank the authors of that document on Temporal Tunnel Services for material that assisted in thinking about this document.
Mehmet Toy、Lei Liu和Khuzema Pithewan为[FRAMEWORK-TTS]的早期版本做出了贡献。我们要感谢关于临时隧道服务的文件的作者提供了有助于思考该文件的材料。
Thanks to Michael Scharf and Daniele Ceccarelli for useful comments on this work.
感谢Michael Scharf和Daniele Ceccarelli对这项工作的有用评论。
Jonathan Hardwick provided a helpful Routing Directorate review.
Jonathan Hardwick提供了一个有用的路由董事会审查。
Deborah Brungard, Mirja Kuehlewind, and Benjamin Kaduk suggested many changes during their Area Director reviews.
Deborah Brungard、Mirja Kuehlewind和Benjamin Kaduk在他们的区域主管审查中提出了许多变化。
Contributors
贡献者
The following person contributed to discussions that led to the development of this document:
以下人员参与了导致本文件编制的讨论：
Dhruv Dhody Email: dhruv.dhody@huawei.com
Dhruv Dhody电子邮件：Dhruv。dhody@huawei.com
Authors' Addresses
作者地址
Yan Zhuang Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区燕庄华为软件大道101号210012
Email: zhuangyan.zhuang@huawei.com
Email: zhuangyan.zhuang@huawei.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区华为软件大道101号秦武210012
Email: bill.wu@huawei.com
Email: bill.wu@huawei.com
Huaimo Chen Huawei Boston, MA United States of America
美国马萨诸塞州波士顿华为公司
Email: huaimo.chen@huawei.com
Email: huaimo.chen@huawei.com
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
Email: afarrel@juniper.net
Email: afarrel@juniper.net