Internet Engineering Task Force (IETF) G. Ash, Ed.
Request for Comments: 6601 AT&T
Category: Experimental D. McDysan
ISSN: 2070-1721 Verizon
April 2012
Internet Engineering Task Force (IETF) G. Ash, Ed.
Request for Comments: 6601 AT&T
Category: Experimental D. McDysan
ISSN: 2070-1721 Verizon
April 2012
Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks
IP/MPLS网络通用连接允许控制（GCAC）算法规范
Abstract
摘要
This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv-aware MPLS Traffic Engineering (DS-TE), Path Computation Element (PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic.
本文介绍了基于IP-/MPLS网络的通用连接允许控制（GCAC）参考模型和算法。服务提供商（SP）IP/MPLS网络需要一个MPLS GCAC机制，作为一个激励性的例子，当额外的呼叫会对正在进行的呼叫产生不利影响时，拒绝IP语音（VoIP）呼叫。如果没有MPLS GCAC，拥塞链路上的连接质量将降低。MPLS GCAC算法可以选择在供应商设备中实现，并由服务提供商部署。MPLS GCAC可在供应商设备之间以及跨多个服务提供商域进行互操作。MPLS GCAC算法为基于MPLS的网络使用可用的标准机制，如RSVP、区分服务感知MPLS流量工程（DS-TE）、路径计算元素（PCE）、信令后续步骤（NSIS）、区分服务和OSPF。MPLS GCAC算法不包括可能被视为供应商专有实现的CAC方面，例如详细的路径选择机制。MPLS GCAC功能以分布式方式实现，以提供特定QoS约束的目标服务质量（QoS）。目标是源能够计算源路由，并且沿所选路径的via元素事实上很可能接纳请求。在某些情况下（例如，多个自治系统（ASE）），这一目标并不总能实现，但本文件总结了部分实现这一目标的方法。MPLS GCAC适用于任何必须满足特定流量的目标QoS（延迟、抖动、丢包率）的服务或流。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc6601.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6601.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. MPLS GCAC Reference Model and Algorithm Summary .................6
2.1. Inputs to MPLS GCAC ........................................8
2.2. MPLS GCAC Algorithm Summary ................................9
3. MPLS GCAC Algorithm ............................................12
3.1. Bandwidth Allocation Parameters ...........................12
3.2. GCAC Algorithm ............................................15
4. Security Considerations ........................................18
5. Acknowledgements ...............................................20
6. Normative References ...........................................20
7. Informative References .........................................21
Appendix A: Example MPLS GCAC Implementation Including Path
Selection, Bandwidth Management, QoS Signaling, and
Queuing ...............................................24
A.1 Example of Path Selection and Bandwidth Management
Implementation .............................................26
A.2 Example of QoS Signaling Implementation ....................32
A.3 Example of Queuing Implementation ..........................34
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. MPLS GCAC Reference Model and Algorithm Summary .................6
2.1. Inputs to MPLS GCAC ........................................8
2.2. MPLS GCAC Algorithm Summary ................................9
3. MPLS GCAC Algorithm ............................................12
3.1. Bandwidth Allocation Parameters ...........................12
3.2. GCAC Algorithm ............................................15
4. Security Considerations ........................................18
5. Acknowledgements ...............................................20
6. Normative References ...........................................20
7. Informative References .........................................21
Appendix A: Example MPLS GCAC Implementation Including Path
Selection, Bandwidth Management, QoS Signaling, and
Queuing ...............................................24
A.1 Example of Path Selection and Bandwidth Management
Implementation .............................................26
A.2 Example of QoS Signaling Implementation ....................32
A.3 Example of Queuing Implementation ..........................34
This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. Given the capital constraints in some SP networks, over-provisioning is not acceptable. MPLS GCAC supports all access technologies, protocols, and services while meeting performance objectives with a cost-effective solution and operates across routing areas, autonomous systems, and service provider boundaries.
本文介绍了基于IP-/MPLS网络的通用连接允许控制（GCAC）参考模型和算法。服务提供商（SP）IP/MPLS网络需要一个MPLS GCAC机制，作为一个激励性的例子，当额外的呼叫会对正在进行的呼叫产生不利影响时，拒绝IP语音（VoIP）呼叫。如果没有MPLS GCAC，拥塞链路上的连接质量将降低。考虑到某些SP网络的资金限制，过度调配是不可接受的。MPLS GCAC支持所有接入技术、协议和服务，同时通过经济高效的解决方案实现性能目标，并跨路由区域、自治系统和服务提供商边界运行。
This document defines an MPLS GCAC reference model, algorithm, and functions implemented in one or more types of network elements in different domains that operate together in a distributed manner to deliver the objective QoS for specified QoS constraints, such as bandwidth. With MPLS GCAC, the source router/server is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. MPLS GCAC includes nested CAC actions, such as RSVP aggregation, nested RSVP - Traffic Engineering (RSVP-TE) for scaling between provider edge (PE) routers, and pseudowire (PW) CAC within traffic-engineered tunnels. MPLS GCAC focuses on MPLS and PW-level CAC functions, rather than application-level CAC functions.
本文档定义了MPLS GCAC参考模型、算法和在不同域中的一种或多种类型的网元中实现的功能，这些网元以分布式方式一起运行，以提供特定QoS约束（如带宽）的目标QoS。使用MPLS GCAC，源路由器/服务器能够计算源路由，并且极有可能沿所选路径的via元素实际上会接纳请求。MPLS GCAC包括嵌套的CAC操作，例如RSVP聚合、用于在提供商边缘（PE）路由器之间扩展的嵌套RSVP-流量工程（RSVP-TE）以及流量工程隧道内的伪线（PW）CAC。MPLS GCAC侧重于MPLS和PW级CAC功能，而不是应用程序级CAC功能。
MPLS GCAC is applicable to any service or flow that must meet an objective QoS (latency, delay variation, loss) for a specified quantity of traffic. This would include, for example, most real-time/RTP services (voice, video, etc.) as well as some non-real-time services. Real-time/RTP services are typically interactive, relatively persistent traffic flows. Other services subject to MPLS GCAC could include, for example, manually provisioned label switched paths (LSPs) or PWs and automatic bandwidth assignment for applications that automatically build LSP meshes among PE routers. MPLS GCAC is applicable to both access and backbone networks, for example, to slow-speed access networks and to broadband DSL, cable, and fiber access networks.
MPLS GCAC适用于任何必须满足特定流量的目标QoS（延迟、延迟变化、丢失）的服务或流。例如，这将包括大多数实时/RTP服务（语音、视频等）以及一些非实时服务。实时/RTP服务通常是交互式的、相对持久的业务流。受MPLS-GCAC约束的其他服务可以包括，例如，手动设置的标签交换路径（LSP）或pw，以及为在PE路由器之间自动构建LSP网格的应用程序自动分配带宽。MPLS GCAC适用于接入网和骨干网，例如，适用于低速接入网和宽带DSL、电缆和光纤接入网。
This document is Experimental. It is intended that service providers and vendors experiment with the GCAC concept and the algorithm described in this document in a controlled manner to determine the benefits of such a mechanism. That is, they should first experiment with the GCAC algorithm in their laboratories and test networks. When testing in live networks, they should install the GCAC algorithm on selected routers in only part of their network, and they should
这份文件是实验性的。服务提供商和供应商旨在以受控的方式试验GCAC概念和本文档中描述的算法，以确定这种机制的好处。也就是说，他们应该首先在实验室和测试网络中试验GCAC算法。在实时网络中进行测试时，他们应该只在部分网络中的选定路由器上安装GCAC算法，并且应该
carefully monitor the effects. The installation should be managed such that the routers can quickly be switched back to normal operation if any problem is seen.
仔细监控效果。应管理安装，以便在发现任何问题时，路由器可以快速切换回正常运行。
Since application of GCAC is most likely in Enterprise VPNs and/or internal TE infrastructure, it is RECOMMENDED that the experiment be conducted in such applications, and it is NOT RECOMMENDED that the experiment be conducted in the Internet. If possible, the experimental configuration will address interoperability issues, such as, for example, the use of different constraint models across different traffic domains.
由于GCAC最有可能应用于企业VPN和/或内部TE基础设施，因此建议在此类应用中进行实验，而不建议在互联网上进行实验。如果可能，实验配置将解决互操作性问题，例如，在不同的流量域中使用不同的约束模型。
The experiment can monitor various measures of quality of service before and after deployment of GCAC, particularly when the experimental network is under stress during an overload or failure condition. These quality-of-service measures might include, for example, dropped packet rate and end-to-end packet delay. The results of such experiments may be fed back to the IETF community to refine this document and to move it to the Standards Track (probably within the MPLS working group) if the experimental results are positive.
该实验可以在部署GCAC之前和之后监控服务质量的各种度量，特别是当实验网络在过载或故障情况下处于压力下时。例如，这些服务质量度量可以包括丢弃的分组速率和端到端分组延迟。如果实验结果是肯定的，则可将此类实验结果反馈给IETF社区，以完善本文件，并将其移至标准轨道（可能在MPLS工作组内）。
It should be noted that the algorithm might have negative effects on live deployments if the experiment is a failure. Effects might include blockage of traffic that would normally be handled or congestion caused by allowing excessive traffic on a link. For these reasons, experimentation in production networks needs to be treated with caution as described above and should only be carried out after successful simulation and experimentation in test environments. In Section 2, we describe the MPLS GCAC reference model, and in Section 3, we specify the MPLS GCAC algorithm based on the principles in the reference model and requirements. Appendix A gives an example of MPLS GCAC implementation including path selection, bandwidth management, QoS signaling, and queuing implementation.
应该注意的是，如果实验失败，该算法可能会对实时部署产生负面影响。影响可能包括正常情况下处理的交通堵塞，或允许链路上出现过多交通堵塞。由于这些原因，生产网络中的实验需要如上所述谨慎对待，并且只能在测试环境中成功模拟和实验后进行。在第2节中，我们描述了MPLS GCAC参考模型，在第3节中，我们根据参考模型中的原则和需求指定了MPLS GCAC算法。附录A给出了MPLS GCAC实现的示例，包括路径选择、带宽管理、QoS信令和队列实现。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Figure 1 illustrates the reference model for the MPLS GCAC algorithm:
图1说明了MPLS GCAC算法的参考模型：
,-. ,-.
,--+ `--+--'- --'\
+----+_____+------+ { +----+ +----+ `. +------+
|GEF1| | |______| P |___| P |______| |
| |-----| PE1 | { +----+ +----+ /+| PE2 |
| | | |==========================>| ASBR |
+-:--+ | |<==========================| |
_|..__ +------+ { DS-TE/MAR Tunnels ; +------+
_,' \-| ./ -'._ !|
| Access \ / +----+ \, !|
| Network | \_ | P | | !|
| / `| +----+ / !|
`--. ,.__,| | IP/MPLS Network / !|
'`' '' ' .._,,'`.__ _/ '---' !|
| '`''' !|
C1 !|
,-. ,-. !|
,--+ `--+--'- --'\ !|
+----+_____+------+ { +----+ +----+ `. +------+
|GEF2| | |______| P |___| P |______| |
| |-----| PE4 | { +----+ +----+ /+| PE3 |
| | | |==========================>| ASBR |
+-:--+ | |<==========================| |
_|..__ +------+ { DS-TE/MAM Tunnels ; +------+
_,' \-| ./ -'._
| Access \ / +----+ \,
| Network | \_ | P | |
| / `| +----+ /
`--. ,.__,| | IP/MPLS Network /
'`' '' ' .._,,'`.__ _/ '---'
| '`'''
C2
,-. ,-.
,--+ `--+--'- --'\
+----+_____+------+ { +----+ +----+ `. +------+
|GEF1| | |______| P |___| P |______| |
| |-----| PE1 | { +----+ +----+ /+| PE2 |
| | | |==========================>| ASBR |
+-:--+ | |<==========================| |
_|..__ +------+ { DS-TE/MAR Tunnels ; +------+
_,' \-| ./ -'._ !|
| Access \ / +----+ \, !|
| Network | \_ | P | | !|
| / `| +----+ / !|
`--. ,.__,| | IP/MPLS Network / !|
'`' '' ' .._,,'`.__ _/ '---' !|
| '`''' !|
C1 !|
,-. ,-. !|
,--+ `--+--'- --'\ !|
+----+_____+------+ { +----+ +----+ `. +------+
|GEF2| | |______| P |___| P |______| |
| |-----| PE4 | { +----+ +----+ /+| PE3 |
| | | |==========================>| ASBR |
+-:--+ | |<==========================| |
_|..__ +------+ { DS-TE/MAM Tunnels ; +------+
_,' \-| ./ -'._
| Access \ / +----+ \,
| Network | \_ | P | |
| / `| +----+ /
`--. ,.__,| | IP/MPLS Network /
'`' '' ' .._,,'`.__ _/ '---'
| '`'''
C2
CUSTOMER I/F PARAMETERS: BW, QoS, CoS, priority
客户I/F参数：BW、QoS、CoS、优先级
NOTE: PE, P, ASBR, GEF elements all support GCFs
注：PE、P、ASBR、GEF要素均支持GCF
LEGEND:
---------
ASBR: Autonomous System Border Router
BW: bandwidth
CoS: class of service
DS-TE: Diffserv-aware MPLS Traffic Engineering
GCAC: generic connection admission control
GCF: GCAC core function
GEF: GCAC edge function
I/F: interface
MAM: Maximum Allocation Model
MAR: Maximum Allocation with Reservation
P: provider router
PE: provider edge router
--- connection signaling
___ bearer/media flows
LEGEND:
---------
ASBR: Autonomous System Border Router
BW: bandwidth
CoS: class of service
DS-TE: Diffserv-aware MPLS Traffic Engineering
GCAC: generic connection admission control
GCF: GCAC core function
GEF: GCAC edge function
I/F: interface
MAM: Maximum Allocation Model
MAR: Maximum Allocation with Reservation
P: provider router
PE: provider edge router
--- connection signaling
___ bearer/media flows
Figure 1: MPLS GCAC Reference Model
图1:MPLS GCAC参考模型
MPLS GCAC is applicable to any service or flow for which MPLS GCAC is required to meet a given QoS. As such, the reference model applies to most real-time/RTP services (voice, video, etc.) as well as some non-real-time services. Real-time/RTP services are typically interactive, relatively persistent traffic flows. Non-real-time applications subject to MPLS GCAC could include, for example, manually provisioned LSPs or PWs and automatic bandwidth assignment for applications that automatically build LSP meshes among PE routers. The reference model also applies to MPLS GCAC when MPLS is used in access networks, which include, for example, slow-speed access networks and broadband DSL, cable, and fiber access networks. Endpoints will be IP/PBXs (Private Branch Exchanges) and individual-usage SIP/RTP end devices (hard and soft SIP phones, Integrated Access Devices (IADs)). This traffic will enter and leave the core via possibly bandwidth-constrained access networks, which may also be MPLS aware but may use some other admission control technology.
MPLS GCAC适用于要求MPLS GCAC满足给定QoS的任何服务或流。因此，参考模型适用于大多数实时/RTP服务（语音、视频等）以及一些非实时服务。实时/RTP服务通常是交互式的、相对持久的业务流。受MPLS GCAC约束的非实时应用程序可以包括，例如，手动配置的LSP或PWs，以及在PE路由器之间自动构建LSP网格的应用程序的自动带宽分配。当MPLS用于接入网络时，参考模型也适用于MPLS GCAC，例如，接入网络包括低速接入网络和宽带DSL、电缆和光纤接入网络。端点将是IP/PBX（专用分支交换机）和个人使用SIP/RTP终端设备（硬和软SIP电话、集成接入设备（IAD））。该流量将通过可能带宽受限的接入网络进入和离开核心，该接入网络也可能是MPLS感知的，但可能使用一些其他准入控制技术。
The basic elements considered in the reference model are the MPLS GCAC edge function (GEF), GCAC core functions (GCFs), the PE routers, Autonomous System Border Routers (ASBRs), and provider (P) routers. As illustrated in Figure 1, the GEF interfaces to the application at the source and destination PE, and the GCF exists at the PE, P, and ASBR routers. GEF has an end-to-end focus and deals with whether individual connection requests fit within an MPLS tunnel, and GCF has a hop-by-hop focus and deals with whether an MPLS tunnel can be established across specific core network elements on a path. The GEF functionality may be implemented in the PE, ASBR, or a stand-alone network element. The source/destination routers (or external devices
参考模型中考虑的基本要素是MPLS GCAC边缘功能（GEF）、GCAC核心功能（GCF）、PE路由器、自治系统边界路由器（ASBR）和提供商（P）路由器。如图1所示，GEF在源PE和目标PE与应用程序接口，GCF存在于PE、P和ASBR路由器。GEF有一个端到端的焦点，处理单个连接请求是否适合MPLS隧道，GCF有一个逐跳的焦点，处理是否可以跨路径上的特定核心网络元素建立MPLS隧道。GEF功能可以在PE、ASBR或独立网元中实现。源/目标路由器（或外部设备）
through a router interface) support both GEF and GCF, while internal routers (or external devices through a router interface) support GCF. In Figure 1, the GEF handles both signaling and bearer control.
通过路由器接口）支持GEF和GCF，而内部路由器（或通过路由器接口的外部设备）支持GCF。在图1中，GEF处理信令和承载控制。
Inputs to the GEF and GCF include the following, where most are inputs to both GEF and GCF, except as noted. Most of the parameters apply to the specific flow/LSP being calculated, while some parameters, such as request type, apply to the calculation method. Required inputs are marked with (*); all other inputs are optional:
对全球环境基金和全球合作框架的投入包括以下内容，其中大多数是对全球环境基金和全球合作框架的投入，除非另有说明。大多数参数适用于正在计算的特定流/LSP，而某些参数（如请求类型）适用于计算方法。所需输入用（*）标记；所有其他输入都是可选的：
Traffic Description * Bandwidth per DS-TE class type [RFC4124] (GEF, GCF) * Bandwidth for LSP from [RFC3270] (GEF, GCF) * Aggregated RSVP bandwidth requirements from [RFC4804] (GEF) Variance Factor (GEF, GCF)
流量描述*每个DS-TE类类型的带宽[RFC4124]（GEF，GCF）*来自[RFC3270]（GEF，GCF）的LSP带宽）*来自[RFC4804]（GEF）的聚合RSVP带宽要求方差系数（GEF，GCF）
Class of Service (CoS) and Quality of Service (QoS) * Class Type (CT) from [RFC4124] (GEF, GCF) Signaled or configured Traffic Class (TC) [RFC5462] to Per Hop Behavior (PHB) mapping from [RFC3270] (GEF, GCF) Signaled or configured PHB from [RFC3270] (GEF, GCF) QoS requirements from NSIS/Y.1541 [RFC5971][RFC5974][RFC5975] [RFC5976] (GEF)
服务类别（CoS）和服务质量（QoS）*类别类型（CT）从[RFC4124]（GEF，GCF）信号或配置的流量类别（TC）[RFC5462]到每跳行为（PHB）的映射从[RFC3270]（GEF，GCF）信号或配置的PHB从[RFC3270]（GEF，GCF）到NSIS/Y.1541[RFC5971][RFC5974][RFC5975][RFC5976]（GEF）的QoS要求
Priority Admission priority (high, normal, best effort) from NSIS/Y.1541 [RFC5971][RFC5974][RFC5975][RFC5976] (GEF, GCF) Preemption priority from [RFC4124] (GEF, GCF)
NSIS/Y.1541[RFC5971][RFC5974][RFC5975][RFC5976]（全球环境基金，全球合作框架）的优先准入优先级（高、正常、尽力而为）和[RFC4124]（全球环境基金，全球合作框架）的抢占优先级
Request type Primary tunnel (GEF, GCF) Backup tunnel and fraction of capacity reserved for backup (GEF, GCF)
请求类型主通道（GEF，GCF）备份通道和为备份保留的容量分数（GEF，GCF）
Oversubscription method (see [RFC3270]) Over/undersubscribe requested capacity (GEF, GCF) Over/undersubscribe available bandwidth (GEF, GCF)
超额订阅方法（参见[RFC3270]）超额/超额订阅请求容量（GEF，GCF）超额/超额订阅可用带宽（GEF，GCF）
These inputs can be received by the GEF and GCF from a signaling interface (such as SIP or H.323), RSVP, or an NMS. They can also be derived from measured traffic levels or from elsewhere.
GEF和GCF可以从信令接口（如SIP或H.323）、RSVP或NMS接收这些输入。它们也可以从测量的流量水平或其他地方得到。
Figure 1 is a reference model for MPLS GCAC and illustrates the GEF to GEF MPLS GCAC algorithm to determine whether there is sufficient bandwidth to complete a connection. The originating GEF receives a connection request including the above input parameters over the input interface, for example, via an RSVP bandwidth request as specified in [RFC4804]. The GEF a) determines whether there is enough bandwidth on the route between the originating and terminating GEFs via routing and signaling communication with the GCFs at the P, PE, and ASBR network elements along the path to accommodate the connection, b) communicates the accept/reject decision on the input interface for the connection request, and c) keeps account of network resource allocations by tracking bandwidth use and allocations per CoS. Optionally, the GEF may dynamically adjust the tunnel size by signaling communication with the GCFs at nodes along the candidate paths. For example, the GEF could a) maintain per-CoS tunnel capacity based on aggregated connection requests and respond on a connection-by-connection basis based on the available capacity, b) periodically adjust the tunnel capacity upward, when needed, and downward when spare capacity exists in the tunnel, and c) use a 'make before break' mechanism to adjust tunnel capacity in order to minimize disruption to the bearer traffic.
图1是MPLS GCAC的参考模型，说明了GEF到GEF MPLS GCAC算法，以确定是否有足够的带宽来完成连接。发起GEF通过输入接口接收包括上述输入参数的连接请求，例如，通过[RFC4804]中规定的RSVP带宽请求。GEF a）通过与路径上的P、PE和ASBR网络元件处的GCF进行路由和信令通信，确定发起和终止GEF之间的路由上是否有足够的带宽以容纳连接，b）在输入接口上为连接请求传达接受/拒绝决定，和c）通过跟踪带宽使用和每个CoS的分配来记录网络资源分配。可选地，GEF可以通过在沿候选路径的节点处发信号通知与gcf的通信来动态地调整隧道大小。例如，GEF可以a）根据聚合的连接请求维持每个CoS的隧道容量，并根据可用容量逐个连接进行响应，b）在需要时定期向上调整隧道容量，在隧道中存在备用容量时定期向下调整隧道容量，和c）使用“先通后断”机制调整隧道容量，以尽量减少对承载交通的干扰。
In the reference model, DS-TE [RFC4124] tunnels are configured between the GEFs based on the traffic forecast and current network utilization. These guaranteed bandwidth DS-TE tunnels are created using RSVP-TE [RFC3209]. DS-TE bandwidth constraints models are applied uniformly within each domain, such as the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model [RFC4126], the Maximum Allocation Model (MAM) [RFC4125], and the Russian Dolls Model (RDM) [RFC4127]. An IGP such as OSPF or IS-IS is used to advertise bandwidth availability by CT for use by the GCF to determine MPLS tunnel bandwidth allocation and admission on core (backbone) links. These DS-TE tunnels are configured based on the forecasted traffic load, and when needed, LSPs for different CTs can take different paths.
在参考模型中，基于流量预测和当前网络利用率，在GEF之间配置DS-TE[RFC4124]隧道。这些保证带宽的DS-TE隧道是使用RSVP-TE[RFC3209]创建的。DS-TE带宽约束模型在每个域内统一应用，例如带保留的最大分配（MAR）带宽约束模型[RFC4126]、最大分配模型（MAM）[RFC4125]和俄罗斯玩偶模型（RDM）[RFC4127]。诸如OSPF或IS-IS之类的IGP用于通过CT宣传带宽可用性，以供GCF用于确定核心（骨干）链路上的MPLS隧道带宽分配和接纳。这些DS-TE隧道根据预测的交通负荷进行配置，需要时，不同CT的LSP可以采用不同的路径。
As described in Section 3, the unreserved link bandwidth on CTc on link k (ULBCck) is the only bandwidth allocation parameter that must be available to the MPLS GCAC algorithm. In the case that a connection is set up across multiple service provider networks, i.e., across multiple routing domains/autonomous systems (ASes), there are several options to enable MPLS GCAC to be implemented:
如第3节所述，链路k上CTc上的无保留链路带宽（ULBCck）是MPLS GCAC算法必须可用的唯一带宽分配参数。在跨多个服务提供商网络（即跨多个路由域/自治系统（ASE））建立连接的情况下，有几个选项可以实现MPLS GCAC：
1. Use [OIF-E-NNI] to advertise ULBCck parameters to the originating GEF, for the full topology of adjacent domains/areas/ASes, as described in Section 3.3.2.1.2 of [OIF-E-NNI]. Note that the
1. 如[OIF-E-NNI]第3.3.2.1.2节所述，使用[OIF-E-NNI]向原始GEF公布相邻域/区域/ASE的完整拓扑结构的ULBCck参数。请注意
option of abstract node summarization described in [OIF-E-NNI] will not suffice since the process of summarization results in loss of topology and capacity usage information. In this manner, the originating GEF can implement the MPLS GCAC algorithm described in Section 3 across multiple domains/areas/ASes.
[OIF-E-NNI]中描述的抽象节点汇总选项将不足以满足要求，因为汇总过程会导致拓扑和容量使用信息丢失。以这种方式，发起GEF可以跨多个域/区域/ASE实现第3节中描述的MPLS GCAC算法。
2. Use [BGP-TE] to advertise ULBCck parameters via BGP to the originating GEF for the full topology of adjacent domains/areas/ASes. In this manner, the originating GEF can implement the MPLS GCAC algorithm described in Section 3 across multiple domains/areas/ASes. However, network providers may be reluctant to divulge full topology and capacity usage information to other providers. Furthermore, [BGP-TE] was never intended to provide full TE topology distribution across ASBRs. Such a mechanism would be neither stable nor scalable.
2. 使用[BGP-TE]通过BGP向原始GEF公布ULBCck参数，以获得相邻域/区域/ASE的完整拓扑。以这种方式，发起GEF可以跨多个域/区域/ASE实现第3节中描述的MPLS GCAC算法。但是，网络提供商可能不愿意向其他提供商透露完整的拓扑和容量使用信息。此外，[BGP-TE]从未打算跨ASBR提供完整的TE拓扑分布。这种机制既不稳定也不可扩展。
3. Use individual AS control and MPLS crankback [RFC4920] to retain originating GEF control. For example, in Figure 1, if a connection crosses the two ASes shown (call them AS1 and AS2), the source GEF1 applies the GCAC algorithm described in Section 3 to the links in AS1, that is, between PE1 and PE2/ASBR in Figure 1. Then, in AS2, the GCF in PE3/ASBR applies the MPLS GCAC algorithm to the links in AS2, that is, between PE3 and PE4 in Figure 1. If the flow is rejected in AS2, crankback signaling is used to inform GEF1. In routing a connection across multiple ASes, e.g., across AS1-->AS2-->AS3, if the flow is rejected, say in AS2, the originating GEF1 can seek an alternate route, perhaps AS1-->AS4-->AS3. This option does not achieve full originating GEF control with the desired full topology visibility across ASes but avoids possible issues with obtaining full topology visibility across ASes.
3. 使用单个AS控制和MPLS回退[RFC4920]来保留原始GEF控制。例如，在图1中，如果连接跨越所示的两个ASE（称为AS1和AS2），则源GEF1将第3节中描述的GCAC算法应用于AS1中的链接，即图1中PE1和PE2/ASBR之间的链接。然后，在AS2中，PE3/ASBR中的GCF将MPLS GCAC算法应用于AS2中的链路，即图1中PE3和PE4之间的链路。如果流程在AS2中被拒绝，则使用回退信号通知GEF1。在跨多个ASE（例如跨AS1-->AS2-->AS3）路由连接时，如果流被拒绝（例如在AS2中），则发起GEF1可以寻找备用路由，可能是AS1-->AS4-->AS3。此选项无法实现在ASE之间具有所需完整拓扑可见性的完整控制，但可以避免在ASE之间获得完整拓扑可见性时可能出现的问题。
4. Use Path Computation Elements (PCEs) [RFC4655] across multiple ASes. PCEs could potentially execute the GCAC algorithm within each AS and communicate/interwork across domains to determine which high-level path can supply the requested bandwidth.
4. 跨多个ASE使用路径计算元素（PCE）[RFC4655]。PCE可能在每个AS内执行GCAC算法，并跨域通信/互通，以确定哪个高级路径可以提供请求的带宽。
In the reference model, the GEFs implement RSVP aggregation [RFC4804] for scalability. The GEF RSVP aggregator keeps a running total of bandwidth usage on the DS-TE tunnel, adding the bandwidth requirements during connection setup and subtracting during connection teardown. The aggregator determines whether or not there is sufficient bandwidth for the connection from that originating GEF to the destination GEF. The destination GEF also checks whether there is enough bandwidth on the DS-TE tunnel from the destination GEF to the originating GEF. The aggregate bandwidth usage on the DS-TE tunnel is also available to the DS-TE bandwidth constraints model. If the available bandwidth is insufficient, then the GEF sends a PATH
在参考模型中，GEFs实现RSVP聚合[RFC4804]以实现可伸缩性。GEF RSVP聚合器在DS-TE隧道上保持运行的总带宽使用量，在连接设置期间增加带宽需求，在连接断开期间减少带宽需求。聚合器确定是否有足够的带宽用于从源GEF到目标GEF的连接。目标GEF还检查从目标GEF到原始GEF的DS-TE隧道上是否有足够的带宽。DS-TE隧道上的总带宽使用量也可用于DS-TE带宽约束模型。如果可用带宽不足，则GEF发送路径
message through the tunnel to the other end, requesting bandwidth using GCFs, and if successful, the source would then complete a new explicit route with a PATH message along the path with increased bandwidth, again invoking GCFs on the path. If the size of the DS-TE tunnel cannot be increased on the primary and alternate LSPs, then when the DS-TE tunnel bandwidth is exhausted, the GEF aggregator sends a message to the endpoint denying the reservation. If the DS-TE tunnels are underutilized, the tunnel bandwidth may be reduced periodically to an appropriate level. In the case of a basic single class TE scenario, there is a single TE tunnel rather than multiple-CT DS-TE tunnels; otherwise, the above GCAC functions remain the same.
消息通过隧道到达另一端，使用GCFs请求带宽，如果成功，则源将使用路径消息沿带宽增加的路径完成新的显式路由，再次调用路径上的GCFs。如果无法在主LSP和备用LSP上增加DS-TE隧道的大小，则当DS-TE隧道带宽耗尽时，GEF聚合器向端点发送拒绝保留的消息。如果DS-TE隧道未充分利用，则可以周期性地将隧道带宽减少到适当的水平。在基本的单类TE场景中，存在单个TE隧道，而不是多个CT DS-TE隧道；否则，上述GCAC功能保持不变。
Optionally, the reference model implements separate queues with Diffserv based on Traffic Class (TC) bits [RFC5462]. For example, these queues may include two Expedited Forwarding (EF) priority queues, with the highest priority assigned to Emergency Telecommunications Service (ETS) traffic and the second priority assigned to normal-priority real-time traffic (alternatively, there could be a single EF queue with dual policers [RFC5865]). Several Assured Forwarding (AF) queues may be used for various data traffic, for example, premium private data traffic and premium public data traffic. A separate best-effort queue may be used for the best-effort traffic. Several DS-TE tunnels may share the same physical link and therefore share the same queue.
可选地，参考模型基于流量类（TC）位[RFC5462]使用Diffserv实现单独的队列。例如，这些队列可能包括两个加速转发（EF）优先级队列，其中最高优先级分配给紧急电信服务（ETS）业务，第二优先级分配给正常优先级实时业务（或者，可能有一个带有双策略的单EF队列[RFC5865]）。多个保证转发（AF）队列可用于各种数据流量，例如，高级私有数据流量和高级公共数据流量。对于尽力而为的流量，可以使用单独的尽力而为队列。多个DS-TE隧道可能共享同一物理链路，因此共享同一队列。
The MPLS GCAC algorithm increases the likelihood that the route selected by the GEF will succeed, even when the LSP traverses multiple service provider networks.
MPLS GCAC算法增加了GEF选择的路由成功的可能性，即使LSP穿越多个服务提供商网络。
Path computation is not part of the GCAC algorithm; rather, it is considered as a vendor proprietary function, although standard IP/MPLS functions may be included in path computation, such as the following:
路径计算不是GCAC算法的一部分；相反，它被视为供应商专有功能，尽管标准IP/MPLS功能可能包括在路径计算中，例如：
a) Path Computation Element (PCE) [RFC4655][RFC4657][RFC5440] to implement inter-area/inter-AS/inter-SP path selection algorithms, including alternate path selection, path reoptimization, backup path computation to protect DS-TE tunnels, and inter-area/inter-AS/inter-SP traffic engineering.
a) 路径计算元件（PCE）[RFC4655][RFC4657][RFC5440]用于实现区域间/AS间/SP间路径选择算法，包括备用路径选择、路径重新优化、备份路径计算以保护DS-TE隧道，以及区域间/AS间/SP间流量工程。
b) Backward-Recursive PCE-Based Computation (BRPC) [RFC5441].
b) 基于PCE的反向递归计算（BRPC）[RFC5441]。
c) Per-Domain Path Computation [RFC5152].
c) 每域路径计算[RFC5152]。
d) MPLS fast reroute [RFC4090] to protect DS-TE LSPs against failure.
d) MPLS快速重路由[RFC4090]，以防止DS-TE LSP出现故障。
e) MPLS crankback [RFC4920] to trigger alternate path selection and enable explicit source routing.
e) MPLS回退[RFC4920]以触发备用路径选择并启用显式源路由。
MPLS GCAC is performed at the GEF during the connection setup attempt phase to determine if a connection request can be accepted without violating existing connections' QoS and throughput requirements. To enable routing to produce paths that will likely be accepted, it is necessary for nodes to advertise some information about their internal CAC states. Such advertisements should not require nodes to expose detailed and up-to-date CAC information, which may result in an unacceptably high rate of routing updates. MPLS GCAC advertises CAC information that is generic (e.g., independent of the actual path selection algorithms used) and rich enough to support any CAC.
MPLS GCAC在连接设置尝试阶段在GEF执行，以确定是否可以在不违反现有连接的QoS和吞吐量要求的情况下接受连接请求。为了使路由能够产生可能被接受的路径，节点必须公布有关其内部CAC状态的一些信息。此类播发不应要求节点公开详细且最新的CAC信息，这可能导致无法接受的高路由更新率。MPLS GCAC发布的CAC信息是通用的（例如，独立于使用的实际路径选择算法），且内容丰富，足以支持任何CAC。
MPLS GCAC defines a set of parameters to be advertised and a common admission interpretation of these parameters. This common interpretation is in the form of an MPLS GCAC algorithm to be performed during MPLS LSP path selection to determine if a link or node can be included for consideration. The algorithm uses the advertised MPLS GCAC parameters (available from the topology database) and the characteristics of the connection being requested (available from QoS signaling) to determine if a link/node will likely accept or reject the connection. A link/node is included if the MPLS GCAC algorithm determines that it will likely accept the connection and excluded otherwise.
MPLS GCAC定义了一组要公布的参数以及这些参数的通用准入解释。这种常见的解释是在MPLS LSP路径选择期间执行MPLS GCAC算法的形式，以确定是否可以包括链路或节点以供考虑。该算法使用公布的MPLS GCAC参数（可从拓扑数据库获得）和被请求连接的特征（可从QoS信令获得）来确定链路/节点是否可能接受或拒绝连接。如果MPLS GCAC算法确定链路/节点可能会接受连接，则会包括该链路/节点，否则会被排除。
MPLS GCAC bandwidth allocation parameters for each DS-TE CT are as defined within DS-TE [RFC4126], OSPF-TE extensions [RFC4203], and IS-IS-TE extensions [RFC5307]. The following parameters are available from DS-TE/TE extensions, advertised by the IGP, and available to the GEF and GCF [RFC4124]. Note that the approach presented in this section is adapted from [PNNI], Appendix B.
每个DS-TE CT的MPLS GCAC带宽分配参数在DS-TE[RFC4126]、OSPF-TE扩展[RFC4203]和IS-IS-TE扩展[RFC5307]中定义。以下参数可从IGP公布的DS-TE/TE扩展中获得，并可供GEF和GCF使用[RFC4124]。请注意，本节介绍的方法改编自[PNNI]，附录B。
MRBk Maximum reservable bandwidth on link k specifies the maximum bandwidth that may be reserved; this may be greater than the maximum link bandwidth, in which case the link may be oversubscribed.
MRBk链路k上的最大可保留带宽指定可保留的最大带宽；这可能大于最大链路带宽，在这种情况下，链路可能被超额订阅。
BWCck Bandwidth constraint for CTc on link k = allocated (minimum guaranteed) bandwidth for CTc on link k.
链路k上CTc的BWCck带宽约束=链路k上CTc的分配（最小保证）带宽。
ULBCck Unreserved link bandwidth on CTc on link k specifies the amount of bandwidth not yet reserved for CTc.
链路k上CTc上的ULBCck未保留链路带宽指定尚未为CTc保留的带宽量。
Note that BWCck and ULBCck are the only DS-TE parameters flooded by the IGP [RFC4124][RFC4203][RFC5307]. For example, when bandwidth reservation is used [RFC4126], ULBCck is calculated and flooded by the IGP as follows:
请注意，BWCck和ULBCck是IGP[RFC4124][RFC4203][RFC5307]淹没的唯一DS-TE参数。例如，当使用带宽预留[RFC4126]时，ULBCck由IGP计算并按如下方式泛洪：
RBTk Reservation bandwidth threshold for link k.
链路k的RBTk保留带宽阈值。
ULBCck Unreserved link bandwidth on CTc on link k specifies the amount of bandwidth not yet reserved for CTc, taking RBTk into account,
链路k上CTc上的ULBCck Unreserved link bandwidth指定尚未为CTc保留的带宽量，同时考虑RBTk，
ULBCck = ULBk - delta0/1(CTck) * RBTk
where
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck >= BWCck
ULBCck = ULBk - delta0/1(CTck) * RBTk
where
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck >= BWCck
Also derivable at the GEF and GCF is MRBCck, the maximum reservable link bandwidth for CTc. For example, when bandwidth reservation is used [RFC4126], MRBCck is calculated as follows:
在GEF和GCF中还可以推导出MRBCck，即CTc的最大可保留链路带宽。例如，当使用带宽预留[RFC4126]时，MRBCck的计算如下：
MRBCck Maximum reservable link bandwidth for CTc on link k specifies the amount of bandwidth not yet reserved for CTc.
MRBCck链路k上CTc的最大可保留链路带宽指定尚未为CTc保留的带宽量。
MRBCck = MRBk - delta0/1(CTck) * RBTk
where
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck >= BWCck
MRBCck = MRBk - delta0/1(CTck) * RBTk
where
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck >= BWCck
Note that these bandwidth parameters must be configured in a consistent way within domains and across domains. GEF routing of LSPs is based on ULBCck, where ULBk is available and RBTk can be accounted for by configuration, e.g., RBTk typically = .05 * MRBk.
请注意，这些带宽参数必须在域内和跨域以一致的方式配置。LSP的GEF路由基于ULBCck，其中ULBk可用，RBTk可以通过配置进行说明，例如，RBTk通常=.05*MRBk。
Also available are administrative weight (denoted as "link cost" in [RFC2328]), TE metric [RFC3630], and administrative group (also called color) 4-octet mask [RFC3630].
还可以使用管理权重（在[RFC2328]中表示为“链路成本”）、TE度量[RFC3630]和管理组（也称为颜色）4八位掩码[RFC3630]。
The following quantities can be derived from information advertised by the IGP and otherwise available to the GEF and GCF:
以下数量可从IGP公布的信息以及GEF和GCF可获得的其他信息中得出：
RBWck Reserved bandwidth on CTc on link k (0 <= c <= MaxCT-1).
链路k上CTc上的RBWck保留带宽（0<=c<=MaxCT-1）。
RBWck = total amount of bandwidth reserved by all established LSPs that belong to CTc RBWck = BWCck - ULBCck.
RBWck=属于CTc的所有已建立LSP保留的带宽总量RBWck=BWCK-ULBCck。
ULBk Unreserved link bandwidth on link k specifies the amount of bandwidth not yet reserved for any CT.
链路k上的ULBk未保留链路带宽指定尚未为任何CT保留的带宽量。
ULBk = MRBk - sum [RBWck (0 <= c <= MaxCT-1)].
ULBk=MRBk-总和[RBWck（0<=c<=MaxCT-1）]。
The GCAC algorithm assumes that a DS-TE bandwidth constraints model is used uniformly within each domain (e.g., MAR [RFC4126], MAM [RFC4125], or RDM [RFC4127]). European Advanced Networking Test Center (EANTC) testing [EANTC] has shown that interoperability is problematic when different DS-TE bandwidth constraints models are used by different network elements within a domain. Specific testing of MAM and RDM across different vendor equipment showed the incompatibility. However, while the characteristics of the 3 DS-TE bandwidth constraints models are quite different, it is necessary to specify interworking between them even though it could be complex.
GCAC算法假设DS-TE带宽约束模型在每个域内统一使用（例如，MAR[RFC4126]、MAM[RFC4125]或RDM[RFC4127]）。欧洲高级网络测试中心（EANTC）测试[EANTC]表明，当域内的不同网元使用不同的DS-TE带宽约束模型时，互操作性存在问题。在不同供应商设备上对MAM和RDM进行的具体测试表明不兼容。然而，虽然3个DS-TE带宽约束模型的特征有很大不同，但有必要指定它们之间的互通，即使这可能很复杂。
The following parameters are also defined and available to GCF and are assumed to be locally configured to be a consistent value across all nodes and domain(s):
以下参数也已定义并可供GCF使用，并假定在本地配置为所有节点和域的一致值：
SBWck Sustained bandwidth for CTc on link k (aggregate of existing connections).
SBWck链路k上CTc的持续带宽（现有连接的聚合）。
SBWck = factor * RBWck where factor is configured based on standard 'demand overbooking' factors.
SBWck=系数*RBWck，其中系数是根据标准“需求超售”系数配置的。
VFck Variance factor for CTc on link k; VFck is BWMck normalized by variance of SBWck. VFck is configured based on typical traffic variability statistics.
链路k上CTc的VFck方差因子；VFck是由SBWck的方差归一化的BWMck。VFck是根据典型的流量变化统计信息配置的。
In many implementations of the Private Network-Network Interface (PNNI) GCAC algorithm, the variance factor is not included, or equivalently, VFck is assumed to be zero. A simplified MPLS GCAC algorithm is also derived assuming VFck = 0.
在专用网络接口（PNNI）GCAC算法的许多实现中，不包括方差因子，或者等效地，假设VFck为零。假设VFck=0，还导出了简化的MPLS GCAC算法。
Note that different demand overbooking factors can be specified for each CT, e.g., no overbooking might be used for constant bitrate services, while a large overbooking factor might be used for bursty variable bitrate services. We specify demand overbooking rather than link overbooking for the GCAC algorithm; one advantage is the demand overbooking is compatible with source routing used by the GCAC algorithm.
请注意，可以为每个CT指定不同的需求超售系数，例如，恒定比特率服务可能不使用超售，而突发可变比特率服务可能使用较大的超售系数。我们为GCAC算法指定了需求超售，而不是链路超售；一个优点是需求超售与GCAC算法使用的源路由兼容。
Also defined is
还定义了
BWMck bandwidth margin for CTc on link k; BWMck = RBWck - SBWck
BWMck bandwidth margin for CTc on link k; BWMck = RBWck - SBWck
GEF uses BWCck, RBWck, ULBCck, SBWck, BWMck, and VFck for LSP/IGP routing. GEF also needs to track per-CT LSP bandwidth allocation and reserved bandwidth parameters, which are defined as follows:
GEF使用BWCK、RBWck、ULBCck、SBWck、BWMck和VFck进行LSP/IGP路由。GEF还需要跟踪每CT LSP带宽分配和保留带宽参数，其定义如下：
RBWLcl reserved bandwidth for CTc on LSP l
在LSP l上为CTc保留的RBWLcl带宽
UBWLcl unreserved bandwidth for CTc on LSP l
LSP l上CTc的UBWLcl无保留带宽
The assumption behind the MPLS GCAC is that the ratio between the bandwidth margin that the node is putting above the sustained bandwidth and the standard deviation of the sustained bandwidth does not change significantly as one new aggregate flow is added on the link. Any ingress node doing path selection can then compute the new standard deviation of the aggregate rate (from the old value and the aggregate flow's traffic descriptors) and an estimate of the new BWMck. From this, the increase in bandwidth required to carry the new aggregate flow can be computed and compared to BWCck.
MPLS GCAC背后的假设是，当在链路上添加一个新的聚合流时，节点置于持续带宽之上的带宽裕度与持续带宽的标准偏差之间的比率不会发生显著变化。然后，进行路径选择的任何入口节点都可以计算聚合速率的新标准偏差（来自旧值和聚合流的流量描述符）和新BWMck的估计值。由此，可以计算承载新聚合流所需的带宽增加，并与BWCck进行比较。
To expand on the discussion above, let RBWck denote the reserved bandwidth capacity, i.e., the amount of bandwidth that has been allocated to existing aggregate flows for CTc on link k by the actual CAC used in the node. BWMck is the difference between RBWck and the aggregate sustained bandwidth (SBWck) of the existing aggregate flows. SBWck can be either the sum of existing aggregate flows' declared sustainable bandwidth (SBWi for aggregate flow i) or a smaller (possibly measured or estimated) value. Let MRBCck denote the maximum reservable bandwidth that is usable by aggregate flows for CTc on link k. The following diagram illustrates the relationship among MRBCck, RBWck, BWMck, SBWck, and ULBCck:
为了展开上面的讨论，让RBWck表示保留带宽容量，即节点中使用的实际CAC已分配给链路k上CTc的现有聚合流的带宽量。BWMck是RBWck和现有聚合流的聚合持续带宽（SBWck）之间的差异。SBWck可以是现有聚合流的声明可持续带宽（聚合流i的SBWi）之和，也可以是更小的（可能测量或估计）值。让MRBCck表示链路k上CTc的聚合流可用的最大可保留带宽。下图说明了MRBCck、RBWck、BWMck、SBWck和ULBCck之间的关系：
|<-- BWMck-->|<----- ULBCck ----->|
|---------------|------------|--------------------|
0 SBWck RBWck MRBCck
|<-- BWMck-->|<----- ULBCck ----->|
|---------------|------------|--------------------|
0 SBWck RBWck MRBCck
The assumption is that BWMck is proportional to some measure of the burstiness of the traffic generated by the existing aggregate flows, this measure being the standard deviation of the aggregate traffic rate defined as the square root of the sum of SBWi(PBWi - SBWi) over all existing aggregate flows, where SBWi and PBWi are declared sustainable and peak bandwidth for aggregate flow i, respectively. This assumption is based on the simple argument that RBWck needs to be some multiple of the standard deviation above the mean aggregate
假设BWMck与现有总流量产生的流量突发性的某些度量成比例，该度量是总流量率的标准偏差，定义为所有现有总流量上SBWi（PBWi-SBWi）之和的平方根，其中，SBWi和PBWi分别被宣布为聚合流i的可持续带宽和峰值带宽。这一假设基于一个简单的论点，即RBWck需要是平均总量以上标准偏差的某个倍数
traffic rate to guarantee some level of packet loss ratio and packet queuing time. Depending on the actual CAC used, the BWMck-to-standard-deviation ratio may vary as aggregate flows are established and taken down. It is reasonable to assume, however, that with a sufficiently large value of RBWck, this ratio will not vary significantly. What this means is a link can advertise its current BWMck-to-standard-deviation ratio (actually in the form of VF, which is the square of this number), and the MPLS GCAC algorithm can use this number to estimate how much bandwidth is required to carry an additional aggregate flow.
保证一定程度的数据包丢失率和数据包排队时间的流量率。根据实际使用的CAC，BWMck与标准偏差的比率可能会随着总流量的确定和减少而变化。但是，可以合理地假设，如果RBWck的值足够大，则该比率不会发生显著变化。这意味着链路可以公布其当前BWMck与标准偏差的比率（实际上是VF的形式，它是这个数字的平方），MPLS GCAC算法可以使用这个数字来估计承载额外聚合流需要多少带宽。
Following the derivation given in [PNNI], Appendix B, the MPLS GCAC algorithm is derived as follows. Consider an aggregate flow bandwidth change request DBWi with peak bandwidth PBWi and sustainable bandwidth SBWi and a link with the following MPLS GCAC parameters: ULBCck, BWMck, and VFck for CTc and link k. Denote the variance (i.e., square of standard deviation) of the aggregate traffic rate by VARk (not advertised). Denote other unadvertised MPLS GCAC quantities by RBWck and SBWck. Then,
根据附录B[PNNI]中给出的推导，MPLS GCAC算法推导如下。考虑具有峰值带宽PBWI和可持续带宽SBWI的总流量带宽变化请求DWWI，以及与以下MPLS GCAC参数的链接：CTC和Link K的ULBCck、BWMCK和VFCK。表示VARk（未公布）的总流量率的方差（即标准偏差的平方）。用RBWck和SBWck表示其他未公布的MPLS GCAC数量。然后
VARk = SUM SBWi*(PBWi-SBWi) (1) over existing aggregate flows i
VARk=现有总流量i上的总SBWi*（PBWi SBWi）（1）
and
和
BWMck**2
VFck = ---------- (2)
VARk
BWMck**2
VFck = ---------- (2)
VARk
Using the above equation, VARk can be computed from the advertised VFck and BWMck as:
使用上述方程式，可以根据公布的VFck和BWMck计算VARk，如下所示：
VARk = (BWMck**2)/VFck.
VARk = (BWMck**2)/VFck.
Let DBWi be the additional bandwidth capacity needed to carry the flow within aggregate sustainable bandwidth SBWi. The MPLS GCAC algorithm basically computes DBWi from the advertised MPLS GCAC parameters and the new aggregate flow's traffic descriptors, and compares it with ULBCck. If ULBCck >= DBWi, then the link is included for path selection consideration; otherwise, it is excluded, i.e.,
假设DBWi是在聚合可持续带宽SBWi内承载流所需的额外带宽容量。MPLS GCAC算法基本上根据公布的MPLS GCAC参数和新聚合流的流量描述符计算DBWi，并将其与ULBCck进行比较。如果ULBCck>=DBWi，则包括链路以供路径选择考虑；否则，将其排除在外，即：。，
If (ULBCck >= DBWi), then include link k; else exclude link k (3)
If (ULBCck >= DBWi), then include link k; else exclude link k (3)
Let BWMcknew denote the bandwidth margin if the new aggregate flow were accepted. Denote other 'new' quantities by RBWcknew, SBWcknew, and VARnew. Then,
如果接受了新的聚合流，则让BWMcknew表示带宽裕度。用RBWCKNOWD、SBWCKNOWD和VARnew表示其他“新”数量。然后
DBWi = BWMcknew - BWMck + SBWi (4)
DBWi = BWMcknew - BWMck + SBWi (4)
since BWMcknew = RBWcknew - SBWcknew, BWMck = RBWck - SBWck, and SBWcknew - SBWck = SBWi. Substituting (4) into (3), rearranging terms, and squaring both sides yield:
因为BWMcknew=rbwcknowd-sbwcknowd、BWMck=RBWck-SBWck和sbwcknowd-SBWck=SBWi。将第（4）项替换为第（3）项，重新排列条款，并对双方进行平方运算，得出：
If ((ULBCck+BWMck-SBWck)**2 >= BWMcknew**2), then include link k;
else exclude link k (5)
If ((ULBCck+BWMck-SBWck)**2 >= BWMcknew**2), then include link k;
else exclude link k (5)
Using the MPLS GCAC assumption made earlier, BWMcknew**2 can be computed as:
使用前面作出的MPLS GCAC假设，BWMcknew**2可计算为：
BWMcknew**2 = VFck * VARnew, (6)
BWMcknew**2 = VFck * VARnew, (6)
Where
哪里
VARnew = VARk + SBWck * (PBWi-SBWi). (7)
VARnew = VARk + SBWck * (PBWi-SBWi). (7)
Substituting (2), (6) and (7) into (5) yields:
将（2）、（6）和（7）替换为（5）得到：
If ((ULBCck+BWMck-SBWi)**2 >= BWMck**2 + VFck*SBWi(PBWi-SBWi)),
then include link k;
else exclude link k (8)
If ((ULBCck+BWMck-SBWi)**2 >= BWMck**2 + VFck*SBWi(PBWi-SBWi)),
then include link k;
else exclude link k (8)
and moving BWMck**2 to the left-hand side and rearranging terms yield
将BWMck**2移到左侧，重新排列收益率
If ((ULBCck-SBWi) * (ULBCck-SBWi+2*BWMck) >= VFck*SBWi(PBWi-SBWi),
then include link k;
else exclude link k (9)
If ((ULBCck-SBWi) * (ULBCck-SBWi+2*BWMck) >= VFck*SBWi(PBWi-SBWi),
then include link k;
else exclude link k (9)
Equation (9) represents the Constrained Shortest Path First (CSPF) method implemented by most vendors and deployed by most service providers in MPLS networks. In general, DBWi is between SBWi and PBWi. So, the above test is not necessary for the cases ULBCck >= PBWi and ULBCck < SBWi. In the former case, the link is included; in the latter case, the link is excluded.
等式（9）表示大多数供应商实施并由MPLS网络中的大多数服务提供商部署的约束最短路径优先（CSPF）方法。一般来说，DBWi介于SBWi和PBWi之间。因此，对于ULBCck>=PBWi和ULBCck<SBWi的情况，不需要进行上述测试。在前一种情况下，包含链接；在后一种情况下，链接被排除在外。
Exclude Include
|<--- link ---->|<-- Test (9)-->|<--- link ----->|
|---------------|---------------|----------------| ULBCck
SBWi PBWi
Exclude Include
|<--- link ---->|<-- Test (9)-->|<--- link ----->|
|---------------|---------------|----------------| ULBCck
SBWi PBWi
Note that VF and BWM are frequently not implemented; equivalently, these quantities are assumed to be zero, in which case Equation (9) becomes
请注意，VF和BWM通常未实施；等效地，假设这些量为零，在这种情况下，方程（9）变为零
If (ULBCck >= SBWi), then include link k; else exclude link k (10)
If (ULBCck >= SBWi), then include link k; else exclude link k (10)
Exclude Include
|<--- link ---->|<--- link ----->|
|---------------|----------------| ULBCck
SBWi PBWi
Exclude Include
|<--- link ---->|<--- link ----->|
|---------------|----------------| ULBCck
SBWi PBWi
PNNI GCAC implementations often do not incorporate the variance factor VF, in which case Equation (10) is used.
PNNI GCAC实施通常不包含方差因子VF，在这种情况下，使用方程（10）。
MPLS GCAC must not reject a best-effort (BE, unassigned bandwidth) aggregate flow request based on bandwidth availability, but it may reject based on other reasons such as the number of BE flows exceeding a chosen threshold. MPLS GCAC defines only one parameter for the BE service category -- maximum bandwidth (MBW) -- to advertise how much capacity is usable for BE flows. The purpose of advertising this parameter is twofold: MBW can be used for path optimization, and MBW = 0 is used to indicate that a link is not accepting any (additional) BE flows.
MPLS GCAC不得基于带宽可用性拒绝最大努力（BE，未分配带宽）聚合流请求，但可能基于其他原因（如BE流的数量超过所选阈值）拒绝。MPLS GCAC只为BE服务类别定义了一个参数——最大带宽（MBW）——以公布BE流的可用容量。公布此参数的目的有两个：MBW可用于路径优化，MBW=0用于指示链路不接受任何（附加）be流。
Demand overbooking of LSP bandwidth is employed and must be compliant with [RFC4124] and [RFC3270] to over-/undersubscribe requested capacity. It is simplest to use only one oversubscription method, i.e., the GCAC algorithm assumes oversubscription of demands per CT, both within domains and for interworking between domains. The motivation is that interworking may be infeasible between domains if different overbooking models are used. Note that the same assumption was made for DS-TE bandwidth constraints models, in that the GCAC algorithm assumes a consistent DS-TE bandwidth constraints model is used within each domain and interoperability of bandwidth constraints models across domains.
采用LSP带宽的需求超售，并且必须符合[RFC4124]和[RFC3270]的要求，以满足超额/不足的请求容量。最简单的方法是只使用一种超额预订方法，即GCAC算法假设每个CT的需求超额预订，包括域内和域之间的互通。其动机是，如果使用不同的超售模式，域之间的互通可能不可行。注意，对于DS-TE带宽约束模型也做出了相同的假设，即GCAC算法假设每个域内使用一致的DS-TE带宽约束模型，以及跨域的带宽约束模型的互操作性。
It needs to be clearly understood that all routers contain local and implementation-specific rules (or algorithms) to help them determine what to do with traffic that exceeds capacity and how to admit new flows. If these rules are poorly designed or implemented with defects, then problems may be observed in the network. Furthermore, the implementation of such algorithms provides a mechanism for attacking the delivery of traffic within the network. In view of this, routers and their software are usually extensively tested before deployment, router vendors are extended a degree of trust, and a "compromised router" (i.e., one on which an attacker has installed
需要清楚地了解，所有路由器都包含本地和特定于实现的规则（或算法），以帮助它们确定如何处理超出容量的流量以及如何接纳新流量。如果这些规则设计不当或实施存在缺陷，则可能会在网络中发现问题。此外，此类算法的实现提供了一种攻击网络内流量传输的机制。有鉴于此，路由器及其软件通常在部署前经过广泛测试，路由器供应商获得一定程度的信任，并被视为“受损路由器”（即攻击者安装的路由器）
their own code) is considered a weak spot in the system. Note that if a router is compromised, it can be made to do substantially more problematic things than simply modifying the admission control algorithm. Implementers are RECOMMENDED to ensure that software modifications to routers are fully secured, and operators are RECOMMENDED to apply security measures (that are outside the scope of this document) to prevent unauthorized updates to router software. Nothing in this document suggests any change to normal software security practices.
他们自己的代码）被认为是系统中的一个弱点。注意，如果一个路由器被破坏，它可以做比简单地修改接纳控制算法更多的有问题的事情。建议实施者确保路由器的软件修改完全安全，建议运营商应用安全措施（不在本文件范围内）以防止对路由器软件进行未经授权的更新。本文档中的任何内容都不表示对正常软件安全实践的任何更改。
The use of a GCAC priority parameter raises possibilities for theft-of-service attacks because users could claim an emergency priority for their flows without real need, thereby effectively preventing serious emergency calls to get through. Several options exist for countering such user attacks at the interface to the user, for example:
GCAC优先级参数的使用增加了服务盗窃攻击的可能性，因为用户可以在没有实际需要的情况下为其流申请紧急优先级，从而有效防止严重的紧急呼叫接通。在与用户的界面上存在几种用于抵御此类用户攻击的选项，例如：
- Only some user groups (e.g., police) are authorized to set the emergency priority bit using a policy applied to RSVP-TE signaling.
- 只有一些用户组（例如，警察）有权使用应用于RSVP-TE信令的策略设置紧急优先级位。
- Any user is authorized to employ the emergency priority bit for particular destination addresses (e.g., police) using a policy applied to RSVP-TE signaling.
- 任何用户都有权使用应用于RSVP-TE信令的策略为特定目的地地址（例如，警察）使用紧急优先级位。
- If an attack occurs, the user/group and actions taken should be logged to trace the attack.
- 如果发生攻击，应记录用户/组和采取的操作以跟踪攻击。
- [RFC5069] identifies a number of security threats against emergency call marking and mapping. Section 6 of [RFC5069] lists security requirements to counter these threats, and those requirements should be followed by implementations of this document.
- [RFC5069]识别了针对紧急呼叫标记和映射的许多安全威胁。[RFC5069]第6节列出了应对这些威胁的安全要求，本文件的实施应遵循这些要求。
- The security requirements listed in Section 11 of [RFC4412] should be followed. These requirements apply to use of the Communications Resource Priority Header for the Session Initiation Protocol (SIP) and concern aspects of authentication and authorization, confidentiality and privacy requirements, protection against denial-of-service attacks, and anonymity.
- 应遵守[RFC4412]第11节中列出的安全要求。这些要求适用于会话发起协议（SIP）的通信资源优先级报头的使用，涉及身份验证和授权、机密性和隐私要求、拒绝服务攻击保护和匿名性等方面。
Within the network, the policy and integrity mechanisms already present in RSVP-TE [RFC3209] can be used to ensure that the MPLS LSP has the right policy and security credentials to assume the signaled priority and bandwidth. Further discussion of this topic for the signaling of priority levels using RSVP can be found in [RFC6401]. Some similarities may also be drawn to the security issues
在网络内，RSVP-TE[RFC3209]中已经存在的策略和完整性机制可用于确保MPLS LSP具有正确的策略和安全凭证，以承担信号优先级和带宽。在[RFC6401]中可以找到关于使用RSVP发送优先级信号的本主题的进一步讨论。安全问题也可能有一些相似之处
surrounding the placement of emergency calls in Internet multimedia systems [RFC5069] although the concepts are only comparable at the highest levels.
围绕互联网多媒体系统中紧急呼叫的位置[RFC5069]，尽管这些概念仅在最高级别上具有可比性。
Like any algorithm, the algorithm specified in this document operates on data that is supplied as input parameters. That data is assumed to be collected and stored locally (i.e., on the router performing the algorithm). It is a fundamental assumption of the secure operation of any router that the data stored on that router cannot be externally modified. In this particular case, it is important that the input parameters to the algorithm cannot be influenced by an outside party. Thus, as with all configuration parameters on a router, the implementer MUST supply and the operator is RECOMMENDED to use security mechanisms to protect writing of the configuration parameters for this algorithm.
与任何算法一样，本文中指定的算法对作为输入参数提供的数据进行操作。假设该数据在本地收集和存储（即，在执行算法的路由器上）。任何路由器安全运行的基本假设是，存储在该路由器上的数据不能从外部修改。在这种特殊情况下，重要的是算法的输入参数不能受到外部因素的影响。因此，与路由器上的所有配置参数一样，实现者必须提供，并且建议操作员使用安全机制来保护该算法配置参数的写入。
The authors greatly appreciate Adrian Farrel's support in serving as the sponsoring Area Director for this document and for his valuable comments and suggestions on the document. The authors also greatly appreciate Young Lee serving as the document shepherd and his valuable comments and suggestions. Finally, Robert Sparks' thorough review and helpful suggestions are sincerely appreciated.
作者非常感谢阿德里安·法雷尔（Adrian Farrel）作为本文件的赞助区域主任所给予的支持，以及他对本文件的宝贵意见和建议。作者也非常感谢年轻的李作为文件管理员和他的宝贵意见和建议。最后，我们衷心感谢Robert Sparks的全面审查和有益的建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[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.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124]Le Faucheur，F.，编辑，“支持区分服务感知MPLS流量工程的协议扩展”，RFC 41242005年6月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC4804] Le Faucheur, F., Ed., "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", RFC 4804, February 2007.
[RFC4804]Le Faucheur，F.，编辑，“MPLS TE/DS-TE隧道上资源预留协议（RSVP）预留的聚合”，RFC 4804，2007年2月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920]Farrel，A.，Ed.，Satyanarayana，A.，Iwata，A.，Fujita，N.，和G.Ash，“MPLS和GMPLS RSVP-TE的回退信令扩展”，RFC 4920，2007年7月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，2008年10月。
[BGP-TE] Gredler, H., Farrel, A., Medved, J., and S. Previdi, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, March 2012.
[BGP-TE]Gredler，H.，Farrel，A.，Medved，J.，和S.Previdi，“使用BGP的链路状态和TE信息的北向分布”，正在进行的工作，2012年3月。
[EANTC] "Multi-vendor Carrier Ethernet Interoperability Event", Carrier Ethernet World Congress 2006, Madrid Spain, September 2006.
[EANTC]“多供应商运营商以太网互操作性活动”，2006年运营商以太网世界大会，西班牙马德里，2006年9月。
[FEEDBACK] Ashwood-Smith, P., Jamoussi, B., Fedyk, D., and D. Skalecki, "Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol", Work in Progress, June 2003.
[反馈]Ashwood Smith，P.，Jamoussi，B.，Fedyk，D.，和D.Skalecki，“在基于约束的标签分发协议中使用标签交换路径反馈提高拓扑数据库的准确性”，正在进行的工作，2003年6月。
[OIF-E-NNI] Optical Interworking Forum (OIF), "External Network-Network Interface (E-NNI) OSPFv2-based Routing - 2.0 (Intra-Carrier) Implementation Agreement", IA # OIF-ENNI-OSPF-02.0, July 13, 2011.
[OIF-E-NNI]光互通论坛（OIF），“外部网络接口（E-NNI）基于OSPFv2的路由-2.0（运营商内部）实施协议”，IA#OIF-ENNI-OSPF-02.012011年7月13日。
[PNNI] ATM Forum Technical Committee, "Private Network-Network Interface Specification Version 1.1 (PNNI 1.1)", af-pnni-0055.002, April 2002.
[PNNI]ATM论坛技术委员会，“专用网络接口规范1.1版（PNNI 1.1）”，af-PNNI-0055.002，2002年4月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[RFC4125]Le Faucheur，F.和W.Lai，“区分服务感知MPLS流量工程的最大分配带宽约束模型”，RFC 41252005年6月。
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons", RFC 4126, June 2005.
[RFC4126]Ash，J.“区分服务感知MPLS流量工程和性能比较的保留带宽约束最大分配模型”，RFC 4126，2005年6月。
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[RFC4127]Le Faucheur，F.，Ed.“区分服务感知MPLS流量工程的俄罗斯玩偶带宽约束模型”，RFC 4127，2005年6月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412]Schulzrinne，H.和J.Polk，“会话启动协议（SIP）的通信资源优先级”，RFC 4412，2006年2月。
[RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，JP.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4657] Ash, J., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.，Ed.，和JL。Le Roux主编，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069]Taylor，T.，Ed.，Tschofenig，H.，Schulzrinne，H.，和M.Shanmugam，“紧急呼叫标记和映射的安全威胁和要求”，RFC 5069，2008年1月。
[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, February 2008.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“用于建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，2008年2月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[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, April 2009.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）过程”，RFC 54412009年4月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010.
[RFC5865]Baker，F.，Polk，J.，和M.Dolly，“容量允许流量的区分服务代码点（DSCP）”，RFC 5865，2010年5月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 59712010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]Way，J.，Karagiannis，G.，和A.McDonald，“用于服务质量信令的NSIS信令层协议（NSLP）”，RFC 5974，2010年10月。
[RFC5975] Ash, G., Ed., Bader, A., Ed., Kappler, C., Ed., and D. Oran, Ed., "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975]Ash，G.，Ed.，Bader，A.，Ed.，Kappler，C.，Ed.，和D.Oran，Ed.，“服务质量NSIS信令层协议（NSLP）的QSPEC模板”，RFC 59752010年10月。
[RFC5976] Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak, C., and Y. El Mghazli, "Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes", RFC 5976, October 2010.
[RFC5976]Ash，G.，Morton，A.，Dolly，M.，Tarapore，P.，Dvorak，C.，和Y.El-Mghazli，“Y.1541-QOSM：使用Y.1541服务质量等级的网络模型”，RFC 59762010年10月。
[RFC6401] Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP Extensions for Admission Priority", RFC 6401, October 2011.
[RFC6401]Le Faucheur，F.，Polk，J.，和K.Carlberg，“入学优先权的RSVP延期”，RFC 6401，2011年10月。
[TQO] Ash, G., "Traffic Engineering and QoS Optimization of Integrated Voice and Data Networks", Elsevier, 2006.
[TQO]Ash，G.“综合语音和数据网络的流量工程和QoS优化”，爱思唯尔，2006年。
Appendix A: Example MPLS GCAC Implementation Including Path Selection, Bandwidth Management, QoS Signaling, and Queuing
附录A：MPLS GCAC实施示例，包括路径选择、带宽管理、QoS信令和排队
Figure 2 illustrates an example of the integrated voice/data MPLS GCAC method in which bandwidth is allocated on an aggregated basis to the individual DS-TE CTs. In the example method, CTs have different priorities including high-priority, normal-priority, and best-effort-priority services CTs. Bandwidth allocated to each CT is protected by bandwidth reservation methods, as needed, but bandwidth is otherwise shared among CTs. Each originating GEF monitors CT bandwidth use on each MPLS LSP [RFC3031] for each CT, and determines when CT LSP bandwidth needs to be increased or decreased. In Figure 2, changes in CT bandwidth capacity are determined by GEFs based on an overall aggregated bandwidth demand for CT capacity (not on a per-connection/per-flow demand basis). Based on the aggregated bandwidth demand, GEFs make periodic discrete changes in bandwidth allocation, that is, they either increase or decrease bandwidth on the LSPs constituting the CT bandwidth capacity. For example, if aggregate flow requests are made for CT LSP bandwidth that exceeds the current DS-TE tunnel bandwidth allocation, the GEF initiates a bandwidth modification request on the appropriate LSP(s). This may entail increasing the current LSP bandwidth allocation by a discrete increment of bandwidth denoted here as DBW, where DBW is the additional amount needed by the current aggregate flow request. The bandwidth admission control for each link in the path is performed by the GCF based on the status of the link using the bandwidth allocation procedure described below, where we further describe the role of the different parameters (such as the reserved bandwidth threshold RBT shown in Figure 2) in the admission control procedure. Also, the GEF periodically monitors LSP bandwidth use, and if bandwidth use falls below the current LSP allocation, the GEF initiates a bandwidth modification request to decrease the LSP bandwidth allocation to the current level of bandwidth utilization.
图2说明了综合语音/数据MPLS GCAC方法的示例，其中带宽在聚合基础上分配给各个DS-TE CT。在示例方法中，CT具有不同的优先级，包括高优先级、正常优先级和尽力而为优先级服务CT。根据需要，分配给每个CT的带宽由带宽保留方法保护，但带宽在CT之间共享。每个发起GEF监控每个CT的每个MPLS LSP[RFC3031]上的CT带宽使用情况，并确定何时需要增加或减少CT LSP带宽。在图2中，CT带宽容量的变化由GEFs根据CT容量的总体聚合带宽需求（不是基于每个连接/每个流需求）确定。基于聚合带宽需求，GEF对带宽分配进行周期性离散更改，即，它们增加或减少构成CT带宽容量的LSP上的带宽。例如，如果针对超过当前DS-TE隧道带宽分配的CT LSP带宽发出聚合流请求，则GEF在适当的LSP上发起带宽修改请求。这可能需要通过此处表示为DBW的离散带宽增量来增加当前LSP带宽分配，其中DBW是当前聚合流请求所需的额外量。路径中每个链路的带宽接纳控制由GCF基于链路的状态使用下面描述的带宽分配过程来执行，其中我们进一步描述不同参数（例如图2中所示的保留带宽阈值RBT）在接纳控制过程中的作用。此外，GEF定期监控LSP带宽使用，如果带宽使用低于当前LSP分配，GEF将发起带宽修改请求，以将LSP带宽分配降低到当前带宽利用率水平。
HIGH-PRIORITY-CT LSP
+----+======================+----+======================+----+
|GEF1|NORMAL-PRIORITY-CT LSP| VN | |GEF2|
| |======================| |======================| |
| |LOW-PRIORITY/BE-CT LSP| | | |
+----+======================+----+======================+----+
HIGH-PRIORITY-CT LSP
+----+======================+----+======================+----+
|GEF1|NORMAL-PRIORITY-CT LSP| VN | |GEF2|
| |======================| |======================| |
| |LOW-PRIORITY/BE-CT LSP| | | |
+----+======================+----+======================+----+
LEGEND
------
BE - Best Effort
CT - Class Type
GEF - GCAC Edge Function
LSP - Label Switched Path
VN - Via Node
LEGEND
------
BE - Best Effort
CT - Class Type
GEF - GCAC Edge Function
LSP - Label Switched Path
VN - Via Node
o Distributed bandwidth allocation method applied on a per-class-type (CT) LSP basis
o 基于每类类型（CT）LSP的分布式带宽分配方法
o GEF allocates bandwidth to each CTc LSP based on demand
o GEF根据需求为每个CTc LSP分配带宽
- GEF decides CTc LSP bandwidth increase based on
- GEF决定CTc LSP带宽增加基于
+ aggregate flow sustained bandwidth (SBWi) and variance factor VFck
+ 总流量持续带宽（SBWi）和方差因子VFck
+ routing priority (high, normal, best effort)
+ 路由优先级（高、正常、尽力而为）
+ CTc reserved bandwidth (RBWck) and bandwidth constraint (BWCck)
+ CTc保留带宽（RBWck）和带宽约束（BWCK）
+ link reserved bandwidth threshold (RBTk) and unreserved bandwidth (ULBk)
+ 链路保留带宽阈值（RBTk）和非保留带宽（ULBk）
- GEF periodically decreases CTc LSP bandwidth allocation based on bandwidth use
- GEF根据带宽使用情况定期减少CTc LSP带宽分配
o VNs send crankback messages to GEF if DS-TE/MAR bandwidth allocation rules not met
o 如果不符合DS-TE/MAR带宽分配规则，VNs将向GEF发送回退消息
o Link(s) not meeting request excluded from TE topology database before attempting another explicit route computation
o 在尝试另一个显式路由计算之前，从TE拓扑数据库中排除不满足请求的链路
Figure 2: Per-Class-Type (CT) LSP Bandwidth Management
图2：每类类型（CT）LSP带宽管理
GEF uses SBWi, VFck, RBWck, BWCck, RBTk, and ULBk for LSP bandwidth allocation decisions and IGP routing and uses RBWcl and UBWcl to track per-CT LSP bandwidth allocation and reserved bandwidth. In making a CT bandwidth allocation modification, the GEF determines the CT priority (high, normal, or best effort), CT bandwidth-in-use, and CT bandwidth allocation thresholds. These parameters are used to determine whether network capacity can be allocated for the CT bandwidth modification request.
GEF使用SBWi、VFck、RBWck、BWCK、RBTk和ULBk进行LSP带宽分配决策和IGP路由，并使用RBWcl和UBWcl跟踪每个CT LSP带宽分配和保留带宽。在进行CT带宽分配修改时，GEF确定CT优先级（高、正常或最大努力）、使用的CT带宽和CT带宽分配阈值。这些参数用于确定是否可以为CT带宽修改请求分配网络容量。
In OSPF, link-state flooding is used to make status updates. This is a state-dependent routing (SDR) method where CSPF is typically used to alter LSP routing according to the state of the network. In general, SDR methods calculate a path cost for each connection request based on various factors such as the load state or congestion state of the links in the network. In contrast, the example MPLS GCAC algorithm uses event-dependent routing (EDR), where LSP routing is updated locally on the basis of whether connections succeed or fail on a given path choice. In the EDR learning approaches, the path that was last tried successfully is tried again until congested, at which time another path is selected at random and tried on the next connection request. EDR path choices can also be changed with time in accordance with changes in traffic load patterns. Success-to-the-top (STT) EDR path selection, illustrated in Figure 3, uses a simplified decentralized learning method to achieve flexible adaptive routing. The primary path (path-p) is used first if available, and a currently successful alternate path (path-s) is used until it is congested. In the case that path-s is congested (e.g., bandwidth is not available on one or more links), a new alternate path (path-n) is selected at random as the alternate path choice for the next connection request overflow from the primary path. Bandwidth reservation is used under congestion conditions to protect traffic on the primary path. STT-EDR uses crankback when an alternate path is congested at a via node, and the connection request advances to a new random path choice. In STT-EDR, many path choices can be tried by a given connection request before the request is rejected.
在OSPF中，链路状态洪泛用于进行状态更新。这是一种状态相关路由（SDR）方法，其中CSPF通常用于根据网络状态改变LSP路由。通常，SDR方法基于各种因素（如网络中链路的负载状态或拥塞状态）计算每个连接请求的路径成本。相反，示例MPLS-GCAC算法使用事件相关路由（EDR），其中LSP路由根据给定路径选择上的连接成功与否进行本地更新。在EDR学习方法中，最后一次成功尝试的路径将再次尝试，直到阻塞，此时随机选择另一条路径，并在下一个连接请求中尝试。EDR路径选择也可以根据交通负荷模式的变化随时间而变化。图3所示的SuccesstotheTop（STT）EDR路径选择使用简化的分散学习方法来实现灵活的自适应路由。如果可用，首先使用主路径（path-p），并使用当前成功的备用路径（path-s），直到其拥塞为止。在路径s拥塞的情况下（例如，带宽在一个或多个链路上不可用），随机选择新的备用路径（路径n）作为来自主路径的下一个连接请求溢出的备用路径选择。带宽预留在拥塞情况下用于保护主路径上的流量。STT-EDR在通过节点的备用路径拥挤时使用回退，并且连接请求前进到新的随机路径选择。在STT-EDR中，在拒绝请求之前，可以通过给定的连接请求尝试许多路径选择。
Figure 3 illustrates the example MPLS GCAC operation of STT-EDR path selection and admission control combined with per-CT bandwidth allocation. GEF A monitors CT bandwidth use on each CT LSP and determines when CT LSP bandwidth needs to be increased or decreased. Based on the bandwidth demand, GEF A makes periodic discrete changes in bandwidth allocation, that is, either increases or decreases bandwidth on the LSPs constituting the CT bandwidth capacity. If aggregate flow requests are made for CT LSP bandwidth that exceeds the current LSP bandwidth allocation, GEF A initiates a bandwidth modification request on the appropriate LSP(s).
图3说明了STT-EDR路径选择和准入控制与每CT带宽分配相结合的示例MPLS GCAC操作。GEF A监控每个CT LSP上的CT带宽使用情况，并确定何时需要增加或减少CT LSP带宽。基于带宽需求，GEF A对带宽分配进行周期性离散更改，即增加或减少构成CT带宽容量的LSP上的带宽。如果针对超过当前LSP带宽分配的CT LSP带宽发出聚合流请求，GEF A将在适当的LSP上发起带宽修改请求。
|<----- ULBk <= RBTk ---->|
LSP-p |------------------------|-------------------------|
A B E
|<----- ULBk <= RBTk ---->|
LSP-p |------------------------|-------------------------|
A B E
|<-- ULBk <= RBTk -->|
LSP-s |---------------|--------------------|-------------|
A C D E
|<-- ULBk <= RBTk -->|
LSP-s |---------------|--------------------|-------------|
A C D E
Example of STT-EDR routing method:
STT-EDR路由方法示例：
1. If node A to node E bandwidth needs to be modified (say increased by DBW), primary LSP-p (e.g., LSP A-B-E) is tried first.
1. 如果需要修改节点A到节点E的带宽（例如增加DBW），则首先尝试主LSP-p（例如，LSP A-B-E）。
2. Available bandwidth is tested locally on each link in LSP-p. If bandwidth not available (e.g., unreserved bandwidth on link BE is less than the reserved bandwidth threshold and this CT is above its bandwidth allocation), crankback to node A.
2. 可用带宽在LSP-p中的每个链路上进行本地测试。如果带宽不可用（例如，链路BE上的未保留带宽小于保留带宽阈值，并且此CT高于其带宽分配），则返回节点A。
3. If DBW is not available on one or more links of LSP-p, then the currently successful LSP-s (e.g., LSP A-C-D-E) is tried next.
3. 如果DBW在LSP-p的一个或多个链路上不可用，则下一步尝试当前成功的LSP-s（例如，LSP A-C-D-e）。
4. If DBW is not available on one or more links of LSP-s, then a new LSP is searched by trying additional candidate paths until a new successful LSP-n is found or the candidate paths are exhausted.
4. 如果DBW在LSP-s的一个或多个链路上不可用，则通过尝试其他候选路径来搜索新LSP，直到找到新的成功LSP-n或候选路径用尽。
5. LSP-n is then marked as the currently successful path for the next time bandwidth needs to be modified.
5. 然后，LSP-n被标记为下一次需要修改带宽时的当前成功路径。
Figure 3: STT-EDR Path Selection and Per-CT Bandwidth Allocation
图3:STT-EDR路径选择和每CT带宽分配
For example, in Figure 3, if the LSR-A to LSR-E bandwidth needs to be modified, say increased by DBW, the primary LSP-p (A-B-E) is tried first. The bandwidth admission control for each link in the path is performed based on the status of the link using the bandwidth allocation procedure described below, where we further describe the role of the reserved bandwidth RBWck shown in Figure 3 in the admission control procedure. If the first choice LSP cannot admit the bandwidth change, node A may then try an alternate LSP. If DBW is not available on one or more links of LSP-p, then the currently successful LSP-s A-C-D-E (the 'STT path') is tried next. If DBW is not available on one or more links of LSP-s, then a new LSP is searched by trying additional candidate paths (not shown) until a new successful LSP-n is found or all of the candidate paths held in the cache are exhausted. LSP-n is then marked as the currently
例如，在图3中，如果需要修改LSR-A到LSR-E带宽，比如增加DBW，则首先尝试主LSP-p（A-B-E）。使用下面描述的带宽分配过程，基于链路的状态执行路径中每个链路的带宽接纳控制，其中我们进一步描述图3所示的保留带宽RBWck在接纳控制过程中的作用。如果第一选择LSP不能允许带宽变化，则节点A随后可以尝试备用LSP。如果DBW在LSP-p的一个或多个链路上不可用，则下一步将尝试当前成功的LSP-SA-C-D-E（“STT路径”）。如果DBW在LSP-s的一个或多个链路上不可用，则通过尝试其他候选路径（未显示）来搜索新LSP，直到找到新的成功LSP-n或缓存中保存的所有候选路径都已用尽。然后将LSP-n标记为当前
successful path for the next time bandwidth needs to be modified. DBW is set to the additional amount of bandwidth required by the aggregate flow request.
下次需要修改带宽时的成功路径。DBW设置为聚合流请求所需的额外带宽量。
If all cached candidate paths are tried without success, the search then generates a new CSPF path. If a new CSPF calculation succeeds in finding a new path, that path is made the stored path, and the bottom cached path falls off the list. If all cached paths fail and a new CSPF path cannot be found, then the original stored LSP is retained. New requests go through the same routing algorithm again, since available bandwidth, etc., has changed and new requests might be admitted. Also, GEF A periodically monitors LSP bandwidth use (e.g., once each 2-minute interval), and if bandwidth use falls below the current LSP allocation, the GEF initiates a bandwidth modification request to decrease the LSP bandwidth allocation to the currently used bandwidth level. Bandwidth reservation occurs in STT-EDR with PATH/RESV messages per application of [RFC4804].
如果尝试所有缓存的候选路径均未成功，则搜索将生成新的CSPF路径。如果一个新的CSPF计算成功地找到了一个新路径，则该路径将成为存储路径，并且底部缓存的路径将从列表中删除。如果所有缓存路径都失败，并且找不到新的CSPF路径，则会保留原始存储的LSP。新请求再次通过相同的路由算法，因为可用带宽等发生了变化，新请求可能会被接纳。此外，GEF A周期性地监视LSP带宽使用（例如，每2分钟间隔一次），并且如果带宽使用低于当前LSP分配，GEF发起带宽修改请求以将LSP带宽分配降低到当前使用的带宽水平。带宽保留在STT-EDR中，每个[RFC4804]应用程序都有PATH/RESV消息。
In the STT-EDR computation, most of the time the primary path and stored path will succeed, and no CSPF calculation needs to be done. Therefore, the STT-EDR algorithm achieves good throughput performance while significantly reducing link-state flooding control load [TQO]. An analogous method was proposed in the MPLS working group [FEEDBACK], where feedback based on failed path routing attempts is kept by the TE database and used when running CSPF.
在STT-EDR计算中，大部分时间主路径和存储路径将成功，无需进行CSPF计算。因此，STT-EDR算法在显著降低链路状态泛洪控制负载[TQO]的同时实现了良好的吞吐量性能。MPLS工作组[FEEDBACK]提出了一种类似的方法，其中基于失败路径路由尝试的反馈由TE数据库保存，并在运行CSPF时使用。
In the example GCAC method, bandwidth allocation to the primary and alternate LSPs uses the MAR bandwidth allocation procedure, as described below. Path selection uses a topology database that includes available bandwidth on each link. From the topology database pruned of links that do not meet the bandwidth constraint, the GEF determines a list of shortest paths by using a shortest path algorithm (e.g., Bellman-Ford or Dijkstra methods). This path list is determined based on administrative weights of each link, which are communicated to all nodes within the routing domain (e.g., administrative weight = 1 + e x distance, where e is a factor giving a relatively smaller weight to the distance in comparison to the hop count). Analysis and simulation studies of a large national network model show that 6 or more primary and alternate cached paths provide the best overall performance.
在示例GCAC方法中，对主lsp和备用lsp的带宽分配使用MAR带宽分配过程，如下所述。路径选择使用拓扑数据库，其中包括每个链路上的可用带宽。GEF通过使用最短路径算法（例如Bellman-Ford或Dijkstra方法），从不满足带宽约束的链路的拓扑数据库中确定最短路径列表。该路径列表基于每个链路的管理权重来确定，这些权重被传送到路由域内的所有节点（例如，管理权重＝1+e x距离，其中e是相对于跳数给予距离相对较小权重的因子）。对大型国家网络模型的分析和仿真研究表明，6条或6条以上的主缓存路径和备用缓存路径提供了最佳的总体性能。
PCE [RFC4655][RFC4657][RFC5440] is used to implement inter-area/inter-AS/ inter-SP path selection algorithms, including alternate path selection, path reoptimization, backup path computation to protect DS-TE tunnels, and inter-area/inter-AS/inter-SP traffic engineering. The DS-TE tunnels are protected against
PCE[RFC4655][RFC4657][RFC5440]用于实现区域间/AS间/SP间路径选择算法，包括备用路径选择、路径重新优化、备份路径计算以保护DS-TE隧道，以及区域间/AS间/SP间流量工程。DS-TE隧道受到保护，防止
failure by using MPLS Fast Reroute [RFC4090]. OSPF TE extensions [RFC4203] are used to support the TE database (TED) required for implementation of the above PCE path selection methods.
使用MPLS快速重路由[RFC4090]失败。OSPF TE扩展[RFC4203]用于支持实现上述PCE路径选择方法所需的TE数据库（TED）。
The example MPLS GCAC method incorporates the MAR bandwidth constraint model [RFC4126] incorporated within DS-TE [RFC4124]. In DS-TE/MAR, a small amount of reserved bandwidth RBTk governs the admission control on link k. Associated with each CTc on link k are the allocated bandwidth constraints BWCck to govern bandwidth allocation and protection. The reservation bandwidth on a link, RBTk, can be accessed when a given CTc has reserved bandwidth RBWck below its allocated bandwidth constraint BWCck. However, if RBWck exceeds its allocated bandwidth constraint BWCck, then the reservation bandwidth threshold RBTk cannot be accessed. In this way, bandwidth can be fully shared among CTs if available but is otherwise protected by bandwidth reservation methods. Therefore, bandwidth can be accessed for a bandwidth request = DBW for CTc on a given link k based on the following rules:
示例MPLS GCAC方法包含DS-TE[RFC4124]中包含的MAR带宽约束模型[RFC4126]。在DS-TE/MAR中，少量保留带宽RBTk控制链路k上的接纳控制。与链路k上的每个CTc相关联的是分配的带宽约束BWCck，用于管理带宽分配和保护。当给定CTc的预留带宽RBWck低于其分配的带宽约束BWCck时，可以访问链路上的预留带宽RBTk。但是，如果RBWck超过其分配的带宽约束BWCK，则无法访问保留带宽阈值RBTk。通过这种方式，带宽可以在CT之间完全共享（如果可用），但通过带宽保留方法进行保护。因此，可以根据以下规则访问给定链路k上CTc的带宽请求=DBW的带宽：
For an LSP on a high-priority or normal-priority CTc:
对于高优先级或正常优先级CTc上的LSP：
If RBWck = BWCc, admit if DBW = ULBk
If RBWck > BWCc, admit if DBW = ULBk - RBTk;
If RBWck = BWCc, admit if DBW = ULBk
If RBWck > BWCc, admit if DBW = ULBk - RBTk;
or, equivalently:
或者，相当于：
If DBW = ULBCck, admit the LSP.
如果DBW=ULBCck，则接受LSP。
where
哪里
ULBCck = idle link bandwidth on link k for CTc = ULBk -
delta0/1(CTck) x RBWk
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck = BWCck
ULBCck = idle link bandwidth on link k for CTc = ULBk -
delta0/1(CTck) x RBWk
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck = BWCck
For an LSP on a best-effort-priority CTc:
对于最大努力优先级CTc上的LSP：
allocated bandwidth BWCc = 0; Diffserv queuing serves best-effort packets only if there is available link bandwidth.
分配带宽BWCc=0；只有在存在可用链路带宽的情况下，Diffserv队列才能提供尽力而为的数据包。
In setting the bandwidth constraints for CTck, for a normal-priority CTc, the bandwidth constraints (BWCck) on link k are set by allocating the maximum reservable link bandwidth (MRBk) in proportion to the forecast or measured traffic load bandwidth TRAF_LOAD_BWck for CTc on link k. That is:
在设置CTck的带宽约束时，对于正常优先级的CTc，链路k上的带宽约束（BWCck）是通过分配最大可保留链路带宽（MRBk）来设置的，该带宽约束与链路k上CTc的预测或测量的业务负载带宽TRAF_load_BWck成比例。即:
PROPORTIONAL_ BWck =
TRAF_LOAD_ BWck/[S (c) {TRAF_LOAD_ BWck, c=0, MaxCT-1}] x MRBk
PROPORTIONAL_ BWck =
TRAF_LOAD_ BWck/[S (c) {TRAF_LOAD_ BWck, c=0, MaxCT-1}] x MRBk
For a normal-priority CTc: BWCck = PROPORTIONAL_ BWck
对于正常优先级CTc:BWCck=比例uBWCK
For a high-priority CT, the bandwidth constraint BWCck is set to a multiple of the proportional bandwidth. That is:
对于高优先级CT，带宽约束BWCck设置为比例带宽的倍数。即:
For high-priority CTc: BWCck = FACTOR * PROPORTIONAL_ BWck
对于高优先级CTc:BWCck=系数*比例
where FACTOR is set to a multiple of the proportional bandwidth (e.g., FACTOR = 2 or 3 is typical). This results in some over-allocation ('overbooking') of the link bandwidth and gives priority to the high-priority CTs. Normally, the bandwidth allocated to high-priority CTs should be a relatively small fraction of the total link bandwidth, a maximum of 10-15 percent being a reasonable guideline.
其中，系数设置为成比例带宽的倍数（例如，典型情况下，系数=2或3）。这会导致链路带宽的过度分配（“超售”），并优先考虑高优先级CT。通常，分配给高优先级CT的带宽应该是总链路带宽中相对较小的一部分，最大10-15%是一个合理的准则。
As stated above, the bandwidth allocated to a best-effort-priority CTc is set to zero. That is:
如上所述，分配给尽力而为优先级CTc的带宽设置为零。即:
For a best-effort-priority CTc: BWCck = 0
对于最大努力优先级CTc:BWCck=0
Analysis and simulation studies show that the level of reserved capacity RBTk in the range of 3-5% of link capacity provides the best overall performance.
分析和仿真研究表明，保留容量RBTk在链路容量的3-5%范围内的水平提供了最佳的整体性能。
We give a simple example of the MAR bandwidth allocation method. Assume that there are two class types, CT0 and CT1, and a particular link with
我们给出了MAR带宽分配方法的一个简单示例。假设有两个类类型，CT0和CT1，以及一个特定的链接
MRB = 100
MRB = 100
with the allocated bandwidth constraints set as follows:
分配的带宽限制设置如下：
BWC0 = 30 BWC1 = 50
BWC0=30 BWC1=50
These bandwidth constraints are based on the forecasted traffic loads, as discussed above. Either CT is allowed to exceed its bandwidth constraint BWCc as long a there is at least RBW units of spare bandwidth remaining. Assume RBT = 10. So under overload, if
如上所述，这些带宽限制基于预测的流量负载。只要剩余至少RBW单位的备用带宽，任何一台CT都可以超过其带宽限制BWCc。假设RBT=10。所以在过载的情况下，如果
RBW0 = 20 RBW1 = 70
RBW0=20 RBW1=70
Then, for this loading
那么,这个装载,
UBW = 100 - 20 - 70 = 10
UBW = 100 - 20 - 70 = 10
If a bandwidth increase request = 5 = DBW arrives for Class Type 0 (CT0), then accept for CT0 since RBW0 < BWC0 and DBW (= 5) < ILBW (= 10).
如果类类型0（CT0）的带宽增加请求=5=DBW，则接受CT0，因为RBW0<BWC0且DBW（=5）<ILBW（=10）。
If a bandwidth increase request = 5 = DBW arrives for Class Type 1 (CT1), then reject for CT1 since RBW1 > BC1 and DBW (= 5) > ILBW - RBT = 10 - 10 = 0.
如果类类型1（CT1）的带宽增加请求=5=DBW到达，则拒绝CT1，因为RBW1>BC1，DBW（=5）>ILBW-RBT=10-10=0。
Therefore, CT0 can take the additional bandwidth (up to 10 units) if the demand arrives, since it is below its BWC value. CT1, however, can no longer increase its bandwidth on the link, since it is above its BWC value and there is only RBT=10 units of idle bandwidth left on the link. If best effort traffic is present, it can always seize whatever idle bandwidth is available on the link at the moment but is subject to being lost at the queues in favor of the higher-priority traffic.
因此，如果需求到达，CT0可以占用额外的带宽（最多10个单位），因为它低于其BWC值。然而，CT1不能再增加其链路上的带宽，因为它高于其BWC值，并且链路上只剩下RBT=10个空闲带宽单位。如果存在尽力而为的流量，它总是可以占用链路上当前可用的任何空闲带宽，但会在队列中丢失，以利于更高优先级的流量。
On the other hand, if a request arrives to increase bandwidth for CT1 by 5 units of bandwidth (i.e., DBW = 5), we need to decide whether or not to admit this request. Since for CT1,
另一方面，如果有请求将CT1的带宽增加5个带宽单位（即DBW=5），我们需要决定是否接受该请求。一号货柜码头,，
RBW1 > BWC1 (70 > 50), and
DBW > UBW - RBT (i.e., 5 > 10 - 10)
RBW1 > BWC1 (70 > 50), and
DBW > UBW - RBT (i.e., 5 > 10 - 10)
the bandwidth request is rejected by the bandwidth allocation rules given above. Now let's say a request arrives to increase bandwidth for CT0 by 5 units of bandwidth (i.e., DBW = 5). We need to decide whether or not to admit this request. Since for CT0
上述带宽分配规则拒绝带宽请求。现在让我们假设一个请求到达，将CT0的带宽增加5个带宽单位（即DBW=5）。我们需要决定是否接受这个请求。从CT0开始
RBW0 < BWC0 (20 < 30), and
DBW < UBW (i.e., 5 < 10)
RBW0 < BWC0 (20 < 30), and
DBW < UBW (i.e., 5 < 10)
The example illustrates that with the current state of the link and the current CT loading, CT1 can no longer increase its bandwidth on the link, since it is above its BWC1 value and there is only RBW=10 units of spare bandwidth left on the link. But CT0 can take the additional bandwidth (up to 10 units) if the demand arrives, since it is below its BWC0 value.
该示例说明，在链路的当前状态和当前CT加载情况下，CT1不能再增加链路上的带宽，因为它高于其BWC1值，并且链路上只剩下RBW=10个单位的备用带宽。但如果需求到达，CT0可以占用额外的带宽（最多10个单位），因为它低于其BWC0值。
For the example GCAC, the method for bandwidth additions and deletions to LSPs in is as follows. The bandwidth constraint parameters defined in the MAR method [RFC4126] do not change based on traffic conditions. In particular, these parameters defined in [RFC4126], as described above, are configured and do not change until
对于示例GCAC，中LSP的带宽添加和删除方法如下所示。MAR方法[RFC4126]中定义的带宽约束参数不会根据流量条件而改变。特别是，如上所述，在[RFC4126]中定义的这些参数经过配置，直到
reconfigured: MRBk, BWCck, and RBTk. However, the reserved bandwidth variables change based on traffic: RBWck, ULBk, and ULBCck. The RBWck and bandwidth allocated to each DS-TE/MAR tunnel is dynamically changed based on traffic: it is increased when the traffic demand increases (using RSVP aggregation), and it is periodically decreased when the traffic demand decreases. Furthermore, if tunnel bandwidth cannot be increased on the primary path, an alternate LSP path is tried. When LSP tunnel bandwidth needs to be increased to accommodate a given aggregate flow request, the bandwidth is increased by the amount of the needed additional bandwidth, if possible. The tunnel bandwidth quickly rises to the currently needed maximum bandwidth level, wherein no further requests are made to increase bandwidth, since departing flows leave a constant amount of available or spare bandwidth in the tunnel to use for new requests. Tunnel bandwidth is reduced every 120 seconds by 0.5 times the difference between the allocated tunnel bandwidth and the current level of the actually utilized bandwidth (i.e., the current level of spare bandwidth). Analysis and simulation modeling results show that these parameters provide the best performance across a number of overload and failure scenarios.
重新配置：MRBk、BWCck和RBTk。但是，保留带宽变量会根据流量而变化：RBWck、ULBk和ULBCck。分配给每个DS-TE/MAR隧道的RBWck和带宽根据流量动态变化：当流量需求增加时，RBWck和带宽会增加（使用RSVP聚合），当流量需求减少时，RBWck和带宽会定期减少。此外，如果不能在主路径上增加隧道带宽，则尝试备用LSP路径。当需要增加LSP隧道带宽以适应给定的聚合流请求时，如果可能，带宽将增加所需的额外带宽。隧道带宽迅速上升到当前所需的最大带宽水平，其中没有进一步的请求来增加带宽，因为离开的流在隧道中留下恒定数量的可用或空闲带宽以用于新的请求。隧道带宽每120秒减少0.5倍于分配的隧道带宽和实际使用带宽的当前水平（即，备用带宽的当前水平）之间的差异。分析和仿真建模结果表明，这些参数在许多过载和故障场景中提供了最佳性能。
The example GCAC method uses Next Steps in Signaling (NSIS) algorithms for signaling MPLS GCAC QoS requirements of individual flows. NSIS QoS signaling has been specified by the IETF NSIS working group and extends RSVP signaling by defining a two-layer QoS signaling model:
示例GCAC方法使用信令（NSIS）算法中的下一步骤来信令单个流的MPLS GCAC QoS需求。NSIS QoS信令已由IETF NSIS工作组指定，并通过定义两层QoS信令模型扩展了RSVP信令：
o NSIS Transport Layer Protocol (NTLP) [RFC5971]
o NSIS传输层协议（NTLP）[RFC5971]
o NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling [RFC5974]
o 用于服务质量信令的NSIS信令层协议（NSLP）[RFC5974]
[RFC5975] defines a QoS specification (QSPEC) object, which contains the QoS parameters required by a QoS model (QOSM) [RFC5976]. A QOSM specifies the QoS parameters and procedures that govern the resource management functions in a QoS-aware router. Multiple QOSMs can be supported by the QoS-NSLP, and the QoS-NSLP allows stacking of QSPEC parameters to accommodate different QOSMs being used in different domains. As such, NSIS provides a mechanism for interdomain QoS signaling and interworking.
[RFC5975]定义QoS规范（QSPEC）对象，该对象包含QoS模型（QOSM）所需的QoS参数[RFC5976]。QOSM指定QoS参数和过程，这些参数和过程控制QoS感知路由器中的资源管理功能。QoS NSLP可以支持多个QoSM，QoS NSLP允许堆叠QSPEC参数，以适应不同域中使用的不同QoSM。因此，NSIS为域间QoS信令和互通提供了一种机制。
The QSPEC parameters defined in [RFC5975] include, among others:
[RFC5975]中定义的QSPEC参数包括：
TRAFFIC DESCRIPTION Parameters:
交通描述参数：
o <Traffic Model> Parameters
o <交通模型>参数
CONSTRAINTS Parameters:
约束参数：
o <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER>
Parameters
o <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER>
Parameters
o <PHB Class> Parameter
o <PHB类>参数
o <DSTE Class Type> Parameter
o <DSTE类类型>参数
o <Y.1541 QoS Class> Parameter
o <Y.1541 QoS类>参数
o <Reservation Priority> Parameter
o <Reservation Priority>参数
o <Preemption Priority> and <Defending Priority> Parameters
o <Preemption Priority> and <Defending Priority> Parameters
The ability to achieve end-to-end QoS through multiple Internet domains is also an important requirement. MPLS GCAC end-to-end QoS signaling ensures that end-to-end QoS is met by applying the Y.1541-QOSM [RFC5976], as now illustrated.
通过多个Internet域实现端到端QoS的能力也是一项重要要求。MPLS GCAC端到端QoS信令通过应用Y.1541-QOSM[RFC5976]确保满足端到端QoS，如下图所示。
The QoS GEF initiates an end-to-end, inter-domain QoS RESERVE message containing the QoS parameters, including for example, <Traffic Model>, <Y.1541 QoS Class>, <Reservation Priority>, and perhaps other parameters for the flow. The RESERVE message may cross multiple domains; each node on the data path checks the availability of resources and accumulating the delay, delay variation, and loss ratio parameters, as described below. If an intermediate node cannot accommodate the new request, the reservation is denied. If no intermediate node has denied the reservation, the RESERVE message is forwarded to the next domain. If any node cannot meet the requirements designated by the RESERVE message to support a QoS parameter, for example, it cannot support the accumulation of end-to-end delay with the <Path Latency> parameter, the node sets a flag that will deny the reservation. Also, parameter negotiation can be done, for example, by setting the <Y.1541 QoS Class> to a lower class than specified in the RESERVE message. When the available <Y.1541 QoS Class> must be reduced from the desired <Y.1541 QoS Class>, say because the delay objective has been exceeded, then there is an incentive to respond to the GEF with an available value for delay in the <Path Latency> parameter. For example, if the available <Path Latency> is 150 ms (still useful for many applications) and the desired QoS is 100 ms (according to the desired <Y.1541 QoS Class>
QoS GEF发起端到端、域间QoS保留消息，该消息包含QoS参数，例如包括<Traffic Model>、<Y.1541 QoS Class>、<Reservation Priority>，并且可能还有流的其他参数。保留消息可以跨多个域；数据路径上的每个节点检查资源的可用性，并累积延迟、延迟变化和丢失率参数，如下所述。如果中间节点无法容纳新请求，则保留将被拒绝。如果没有中间节点拒绝保留，则保留消息将转发到下一个域。如果任何节点不能满足RESERVE消息指定的支持QoS参数的要求，例如，它不能使用<Path Latency>参数来支持端到端延迟的累积，则该节点将设置一个拒绝保留的标志。此外，例如，可以通过将<Y.1541 QoS Class>设置为比保留消息中指定的级别更低的级别来完成参数协商。当可用的<Y.1541 QoS等级>必须从所需的<Y.1541 QoS等级>减少时，比如说因为已经超过了延迟目标，那么就有一种激励，即在<Path Latency>参数中为延迟提供一个可用值来响应GEF。例如，如果可用的<Path Latency>为150 ms（对许多应用程序仍然有用），并且期望的QoS为100 ms（根据期望的<Y.1541 QoS等级>
Class 0), then the response would be that Class 0 cannot be achieved and Class 1 is available (with its 400 ms objective). In addition, the response includes an available <Path Latency> = 150 ms, making acceptance of the available <Y.1541 QoS Class> more likely.
0级），则响应为0级无法实现，1级可用（其目标为400 ms）。此外，响应包括可用的<Path Latency>=150 ms，使得更可能接受可用的<Y.1541 QoS类>。
In this MPLS GCAC example, queuing behaviors for the CT traffic priorities incorporates Diffserv mechanisms and assumes separate queues based on Traffic Class (TC)/CoS bits. The queuing implementation assumes 3 levels of priority: high, normal, and best effort. These queues include two EF priority queues [RFC3246][RFC5865], with the highest priority assigned to emergency traffic (GETS/ETS/E911) and the second priority assigned to normal-priority real-time (e.g., VoIP) traffic. Separate AF queues [RFC2597] are used for data services, such as premium private data and premium public data traffic, and a separate best-effort queue is assumed for the best-effort traffic. All queues have static bandwidth allocation limits applied based on the level of forecast traffic on each link, such that the bandwidth limits will not be exceeded under normal conditions, allowing for some traffic overload. In the MPLS GCAC method, high-priority, normal-priority, and best-effort traffic share the same network; under congestion, the Diffserv priority-queuing mechanisms push out the best-effort-priority traffic at the queues so that the normal-priority and high-priority traffic can get through on the MPLS-allocated LSP bandwidth.
在这个MPLS GCAC示例中，CT流量优先级的排队行为结合了Diffserv机制，并基于流量类别（TC）/CoS位假设单独的队列。队列实现假定3个优先级级别：高优先级、正常优先级和尽力而为优先级。这些队列包括两个EF优先级队列[RFC3246][RFC5865]，最高优先级分配给紧急流量（GETS/ETS/E911），第二优先级分配给正常优先级实时（如VoIP）流量。单独的AF队列[RFC2597]用于数据服务，例如高级私有数据和高级公共数据流量，并且为最佳努力流量假设单独的最佳努力队列。所有队列都根据每个链路上的预测流量水平应用静态带宽分配限制，这样在正常情况下不会超过带宽限制，从而允许一些流量过载。在MPLS-GCAC方法中，高优先级、正常优先级和尽力而为的业务共享同一网络；在拥塞情况下，Diffserv优先级排队机制在队列中推出尽力而为的优先级流量，以便正常优先级和高优先级流量能够通过MPLS分配的LSP带宽。
Authors' Addresses
作者地址
Gerald Ash (editor) AT&T
杰拉尔德·阿什（编辑）美国电话电报公司
EMail: gash5107@yahoo.com
EMail: gash5107@yahoo.com
Dave McDysan Verizon 22001 Loudoun County Pkwy Ashburn, VA 20147
Dave McDysan Verizon 22001 Loudoun County Pkwy Ashburn，弗吉尼亚州20147
EMail: dave.mcdysan@verizon.com
EMail: dave.mcdysan@verizon.com