RFC2212：Specification of Guaranteed Quality of Service，September 1997
本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。
本备忘录描述了在 Internet 中提供保证服务（保证延迟和带宽）所需的网络元素行为。保证服务为端到端数据包排队延迟提供了牢固的（数学上可证明的）界限。该服务使得提供既保证延迟又保证带宽的服务成为可能。本规范遵循 [1] 中描述的服务规范模板。
本文档定义了支持保证服务的网络元素的要求。本备忘录是一系列文件之一，这些文件规定了支持 IP 互联网络中各种服务质量所需的网络元素行为。这些文档中描述的服务在全球互联网和私有 IP 网络中都很有用。
本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是按照 RFC 2119 中的说明进行解释。
本文档基于 [1] 中给出的服务规范模板。有关 IP 协议族内服务质量规范的定义和附加信息，请参阅该文档。
简而言之，本备忘录背后的概念是使用令牌桶来描述流，并且给定流的描述，服务元素（路由器、子网等）计算描述服务元素将如何处理流的各种参数数据。通过组合来自路径中各种服务元素的参数，可以计算一条数据在通过该路径传输时将经历的最大延迟。
重要的是要注意本备忘录的三个特征及其指定的服务：
1. 虽然仔细指定了设置机制必须遵循的要求以实现保证预留，但既没有指定设置机制本身，也没有指定识别流的方法。可以使用 RSVP 等协议、相关路由器的手动配置或 SNMP 等网络管理协议来创建保证预留。该规范有意独立于设置机制。
2. 实现有界延迟要求路径中的每个服务元素都支持保证服务或充分模仿保证服务。然而，这一要求并不意味着保证服务必须部署在整个 Internet 上才能发挥作用。即使部分部署，有保障的服务也能带来明显的好处。如果完全部署在 Intranet 中，该 Intranet 可以在内部支持有保障的服务。ISP 可以在其骨干网中提供有保障的服务，并在客户之间（或 POP 之间）提供有保障的服务。
3. 由于服务元素作为结果产生延迟界限，而不是将延迟界限作为要实现的输入，因此有时假设应用程序无法控制延迟。实际上，有保证的服务使应用程序可以对它们的延迟进行相当大的控制。
简而言之，延迟有两部分：固定延迟（传输延迟等）和排队延迟。固定延迟是所选路径的一个属性，它不是由保证服务决定的，而是由设置机制决定的。只有排队延迟由保证服务确定。并且（如本备忘录后面的方程式所示）排队延迟主要是两个参数的函数：令牌桶（特别是桶大小 b）和应用程序请求的数据速率 (R)。这两个值完全在应用程序的控制之下。换句话说，应用程序通常可以先验地准确估计排队延迟保证服务可能承诺的内容。此外，如果延迟大于预期，应用程序可以以可预测的方式修改其令牌桶和数据速率，以实现更低的延迟。
由符合本文档的一系列网络元素提供的端到端行为是一个有保证的带宽水平，当被监管流使用时，它会为所有符合要求的数据包产生一个没有排队损失的延迟限制服务（假设在流的生命周期内没有网络组件故障或路由变化）。
端到端行为符合流体模型（在下面的网络元素数据处理中描述），因为传递的排队延迟不会超过流体延迟超过指定的误差范围。更准确地说，端到端延迟界限是 [(bM)/R*(pR)/(pr)]+(M+Ctot)/R+Dtot，对于 p>R>=r，并且 (M+Ctot )/R+Dtot 用于 r<=p<=R，（其中 b、r、p、M、R、Ctot 和 Dtot 在本文档后面定义）。
注意：虽然计算端到端延迟所需的每跳误差项由服务模块导出（请参阅下面的导出信息），但收集每跳边界和生成端到端数量所需的机制本规范中未描述应用程序已知的 Ctot 和 Dtot。这些功能由预留设置协议、路由协议或其他网络管理功能提供，不在本文档的范围内。
沿路径提供的最大端到端排队延迟（由 Ctot 和 Dtot 表征）和带宽（由 R 表征）将是稳定的。也就是说，只要端到端路径不改变，它们就不会改变。
保证服务不控制数据包的最小或平均延迟，仅控制最大排队延迟。此外，为了计算数据包将经历的最大延迟，必须确定路径的延迟并将其添加到保证的排队延迟中。（但是，如下所述，可以通过观察任何一个数据包所经历的延迟来计算延迟的保守界限）。
此服务受准入控制。
保证服务保证数据包将在保证的交付时间内到达，并且不会由于队列溢出而被丢弃，前提是流的流量保持在其指定的流量参数内。该服务适用于需要可靠保证数据包将在其源传输后的某个时间到达的应用程序。例如，一些音频和视频“回放”应用程序不能容忍任何数据包在其回放时间之后到达。具有严格实时要求的应用程序也需要有保证的服务。
该服务不会尝试最小化抖动（最小和最大数据包延迟之间的差异）；它仅控制最大排队延迟。因为保证的延迟界限是固定的，所以延迟必须设置得足够大，以涵盖极少见的长时间排队延迟的情况。多项研究表明，绝大多数数据包的实际延迟可能远低于保证延迟。因此，回放应用程序的作者应该注意，数据包通常会比交付期限早得多，并且必须在接收系统进行缓冲，直到应用程序处理它们为止。
该服务代表了网络延迟控制的一个极端。大多数其他提供延迟控制的服务对由此产生的延迟提供的保证要弱得多。为了提供这种高水平的保证，保证服务通常只有在由路径上的每个网络元素（即由路由器和互连路由器的链路）提供时才有用。此外，如导出信息部分所述，服务的有效提供和使用要求用于请求服务的设置协议或其他机制向中间路由器和端点提供服务特征。
网元必须确保服务接近服务的“流体模型”。服务速率为 R 的流体模型本质上是由源和接收器之间的带宽 R 的专用线提供的服务。因此，在以固定速率 R 服务的流体模型中，流量的服务完全独立于任何其他流量的服务。
流的服务级别在每个网络元素处由带宽（或服务速率）R 和缓冲区大小 B 来表征。R 表示流有权使用的链路带宽份额，B 表示网络元素中的缓冲区空间流量可能会消耗。网络元素必须确保其服务以相同的速率与流体模型匹配，并在一个急剧的误差范围内。
保证服务的定义依赖于这样的结果：只要 R 不小于 r，服从令牌桶 (r,b) 并由带宽为 R 的线路提供服务的流的流动延迟受 b/R 的限制。具有服务速率 R 的保证服务，其中 R 是带宽份额，而不是专线的带宽，近似于这种行为。
因此，网络元素必须确保任何数据包的排队延迟小于 b/R+C/R+D，其中 C 和 D 描述了远离流体模型的最大局部偏差。重要的是要强调 C 和 D 是最大值。因此，例如，如果实现中偶尔出现服务中断（可能是由于处理路由更新），则 D 需要足够大，以考虑数据包在服务中断期间可能丢失的时间。（C 和 D 在导出信息一节中有更详细的描述）。
注意：严格来说，这个备忘录只要求一个流接收的服务永远不会比它在流体模型的这种近似下接收到的更差。提供更好的服务是完全可以接受的。例如，如果一个流当前没有使用它的份额，R，诸如加权公平队列之类的算法会暂时为其他流提供未使用的带宽，这是完全可以接受的（实际上是鼓励的）。
作为保证服务的一部分，不允许链接将数据包分段。大于链路 MTU 的数据包必须被监管为不合格，这意味着它们将根据下面监管部分中描述的规则进行监管。
通过向网络元素指定流量 (TSpec) 和所需服务 (RSpec) 来调用保证服务。对具有新的 TSpec 和/或 RSpec 的现有流的服务请求应该被视为新的调用，因为准入控制应该重新应用于流。减少他们的 TSpec 和/或他们的 RSpec 的流（即，他们的新 TSpec/RSpec 严格小于旧的 TSpec/RSpec，根据下面的排序部分中描述的排序规则）永远不应该被拒绝服务。
TSpec 采用令牌桶加上峰值速率 (p)、最小监管单元 (m) 和最大数据包大小 (M) 的形式。
令牌桶具有桶深度 b 和桶速率 r。b 和 r 都必须是正数。速率 r 以每秒 IP 数据包字节数为单位，范围从每秒 1 字节到每秒 40 TB（或接近被认为是单股光纤的最大理论带宽）。显然，特别是对于大带宽，只有前几个数字是有效的，因此鼓励使用浮点表示，精度至少为 0.1%。
存储桶深度 b 也以字节为单位，范围从 1 字节到 250 GB。同样，鼓励精确到至少 0.1% 的浮点表示。
值的范围故意较大以允许未来的带宽。该范围并不意味着网络元素必须支持整个范围。
峰值速率 p 以每秒 IP 数据包字节数为单位，具有与桶速率相同的范围和建议表示。峰值速率是源和任何整形点（整形点在下面定义）可以将突发流量注入网络的最大速率。更准确地说，要求对于所有时间段，发送的数据量不能超过 M+pT，其中 M 是最大数据包大小，T 是时间段的长度。此外，p 必须大于或等于令牌桶速率 r。如果峰值速率未知或未指定，则 p 必须设置为无穷大。
最小监管单位 m 是一个以字节为单位的整数。所有大小小于 m 的 IP 数据包在被监管和测试是否符合 TSpec 时都将被计算为大小为 m。最大数据包大小 M 是符合流量规范的最大数据包；它也以字节为单位。如果请求的最大数据包大小大于链路的 MTU，则必须拒绝流。m 和 M 都必须是正数，并且 m 必须小于或等于 M。
保证服务使用参考文献 [8] 中定义的通用 TOKEN_BUCKET_TSPEC 参数来描述数据流的流量特征。上面的描述是关于那个参数的。TOKEN_BUCKET_TSPEC 是第 127 号通用参数。将这个参数用于保证服务 TSpec 简化了多服务环境中保证服务的使用。
RSpec 是一个速率 R 和一个弹性项 S，其中 R 必须大于或等于 r 并且 S 必须是非负的。速率 R 再次以每秒 IP 数据包的字节数来衡量，具有与桶和峰值速率相同的范围和建议表示。弹性项 S 以微秒为单位。RSpec 速率可以大于 TSpec 速率，因为更高的速率会减少排队延迟。弹性项表示期望延迟与使用预留级别 R 获得的延迟之间的差异。网络元件可以利用该弹性项来减少其对该流的资源预留。当网络元素选择利用 RSpec 中的一些 slack 时，它必须遵循特定的规则来更新 RSpec 的 R 和 S 字段；这些规则在排序和合并部分中指定。如果在服务调用时没有指定弹性，则弹性项 S 设置为零。RSpec 中不包含缓冲区规范，因为预计网络元素会派生所需的缓冲区空间，以确保 TSpec 中的令牌桶和峰值速率没有排队丢失，RSpec 中的保留速率和弹性，导出的信息在网络元素，即 Ctot 和 Dtot 或 Csum 和 Dsum，与有关该元素如何管理其流量的内部信息相结合。
TSpec 可以由三个单精度 IEEE 浮点格式的浮点数后跟两个网络字节顺序的 32 位整数表示。第一个浮点值是速率 (r)，第二个浮点值是桶大小 (b)，第三个浮点值是峰值速率 (p)，第一个整数是最小监管单元 (m)，以及第二个整数是最大数据包大小（M）。
RSpec 速率项 R 也可以使用单精度 IEEE 浮点数表示。
Slack 项 S 可以表示为 32 位整数。它的值可以从 0 到 (2^32)-1 微秒。
当 r、b、p 和 R 项表示为 IEEE 浮点值时，符号位必须为零（所有值必须为非负数）。禁止使用小于 127（即 0）的指数。不鼓励使用大于 162（即正 35）的指数，除非指定无穷大的峰值速率。无穷大用全为 1 的指数 (255) 以及全零的符号位和尾数来表示。
每个保证服务模块必须至少导出以下信息。下面描述的所有参数都是表征参数。
一个网络元素的保证服务的实现由两个错误项 C 和 D 来表征，它们表示该元素的保证服务的实现如何偏离流体模型。这两个参数有一个加法合成规则。
误差项 C 是与速率相关的误差项。它表示由于流的速率参数，流中的数据包可能经历的延迟。这种错误项的一个例子是需要考虑串行化数据包所花费的时间，这些数据包被分解成 ATM 信元，信元以 1/r 的频率发送。
注意：重要的是要注意，在计算延迟界限时，参数 C 除以保留率 R。这种除法是因为与序列化数据包的示例一样，C 项的效果是传输速率。实施者应注意确认他们的 C 值除以不同的比率时，会给出适当的结果。不依赖于速率的延迟值应该包含在 D 参数的值中。
误差项 D 是与速率无关的每个元素的误差项，表示通过服务元素的最坏情况下的非基于速率的传输时间变化。它通常在引导或配置时确定或设置。D 的一个示例是时隙网络，其中保证流在时隙循环中被分配特定时隙。每流延迟的某些部分可以由循环中的哪些时隙分配给流来确定。在这种情况下，D 将测量一个流的数据，一旦准备好发送，可能必须等待一个时隙的最长时间。（请注意，这个值可以在分配时隙之前计算出来，因此可以被通告。例如，假设有 100 个时隙。在最坏的情况下，一个流可能会将其所有 N 个时隙聚集在一起，这样如果一个数据包是在集群结束后准备发送，数据包可能需要等待 100-N 个时隙才能发送。在这种情况下，可以通过将 D 设置为 100 个时隙来轻松近似此延迟）。
如果沿整个路径应用组合函数来计算 C 和 D（Ctot 和 Dtot）的端到端总和，然后将结果值提供给端节点（可能通过设置协议），端节点可以计算最大数据包排队延迟。此外，如果从最近的整形点（整形点在下面定义）下游到接收器的部分和（Csum 和 Dsum）被传递给每个网络元素，那么这些网络元素可以计算实现不丢失数据包所必需的缓冲区分配，如在实施者指南一节中有详细说明。正确使用和提供此服务需要计算量 Ctot 和 Dtot，以及量 Csum 和 Dsum。因此，我们假设保证服务的使用将主要在这些数量可供终端节点和网络元素使用的环境中使用。
误差项 C 以字节为单位测量。单个元素可以宣传 1 到 2^28（略超过 250 兆字节）之间的 C 值，并且所有元素的总添加值可以高达 (2^32)-1。如果不同元素延迟的总和超过 (2^32)-1，端到端误差项必须设置为 (2^32)-1。
误差项 D 以一微秒为单位进行测量。单个元素可以宣传 1 到 2^28 之间的延迟值（稍微超过两分钟），并且添加到所有元素的总延迟范围可以高达 (2^32)-1。如果不同元素延迟的总和超过 (2^32)-1，端到端延迟必须设置为 (2^32)-1。
保证服务是 service_name 2。
RSpec 参数编号为 130。
错误表征参数 C 和 D 编号为 131 和 132。C 和 D 的端到端组合值（Ctot 和 Dtot）编号为 133 和 134。C 和 D 的自上次整形点组合值（Csum和 Dsum) 编号为 135 和 136。
有保证的服务有两种监管形式。一种形式是简单监管（以下简称监管以与其他文档保持一致），其中将到达的流量与 TSpec 进行比较。另一种形式是整形，尝试恢复（可能失真）流量的形状以符合 TSpec，并且发现流量违反 TSpec 的事实是因为整形失败（整形缓冲区溢出）。
监管在网络边缘完成。在所有异构源分支点和所有源合并点进行整形。异构源分支点是多播分发树从一个源分支到多个不同路径的点，并且各个传出链路上的保留的TSpec都不相同。仅当传出链路上的 TSpec“小于”（在排序部分中描述的意义上）在紧邻上游链路上保留的 TSpec 时才需要进行整形。源合并点是来自两个不同源（共享相同预留）的分布路径或树合并的地方。服务调用者（设置协议、本地配置工具或类似机制）有责任确定需要监管的点。可以在其他点以及上述那些点处进行整形。除在网络边缘外，不得进行监管。
令牌桶和峰值速率参数要求流量必须遵守规则，即在所有时间段内，发送的数据量不能超过 M+min[pT, rT+bM]，其中 r 和 b 是令牌桶参数，M 是最大数据包大小，T 是时间段的长度（请注意，当 p 为无限时，这会降低到标准令牌桶要求）。出于此计费的目的，链路必须将小于最小监管单元的数据包计数为大小为 m。到达一个元素并导致违反 M+min[pT, rT+b-M] 界限的数据包被认为是不合格的。
在网络边缘，流量受到监管，以确保其符合令牌桶。不合格的数据包应该被视为尽力而为的数据包。[如果并且当标记能力变得可用时，这些不符合要求的数据包应该被“标记”为不符合要求，然后在所有后续路由器中被视为尽力而为数据包。]
尽力而为服务被定义为网络元素将提供给不属于流的数据包的默认服务，该数据包在流的源和目标之间发送。除其他含义外，此定义意味着如果将流的数据包更改为尽力而为数据包，则通常应用于尽力而为数据包的所有流控制（例如，RED [2]）也应用于该数据包。
注意：可能存在本文档范围之外的情况，例如当服务模块的保证服务实现被用于实现流量共享而不是服务质量时，所需的操作是丢弃不合格的数据包。为了允许这样的使用，实现者应该确保对不合格数据包采取的行动是可配置的。
在网络内部，监管不会产生预期的结果，因为排队效应偶尔会导致进入网络的流量在某些下游网络元素处不再符合要求。因此，在网络内部，希望监管流量的网络元素必须通过整形令牌桶的流量来做到这一点。整形需要延迟数据包，直到它们符合 TSpec。
整形是通过将缓冲区与令牌桶和峰值速率调节器组合并缓冲数据直到可以按照令牌桶和峰值速率参数发送的。（令牌桶调节器必须从其充满令牌的令牌桶开始）。在保证服务的情况下，将任何符合要求的流量重新整形回其原始令牌桶形状所需的缓冲量为 b+Csum+(Dsum*r)，其中 Csum 和 Dsum 是最后一个整形点和之间的参数 C 和 D 的总和当前的整形点。请注意，整形器峰值速率的知识可用于减少这些缓冲区需求（请参阅下面的“实施者指南”部分）。网络元素必须提供必要的缓冲区，以确保一致的流量不会在整形器中丢失。
注意：通过观察流的排队流量何时超过 b+Csum+(Dsum*r)，可以观察到未进行整形的路由器仍然可以识别不合格的数据包（并丢弃它们或将它们安排在较低的优先级上）。
如果数据包到达时发现整形缓冲区已满，则该数据包不合格。请注意，这意味着整形者也在有效地进行监管。与监管者一样，整形者应该尽最大努力将不合格的数据包降级。[如果标记可用，不合格的数据包应该被标记]
注意：与监管器一样，应该可以配置整形器如何处理不合格的数据包。
请注意，虽然大缓冲区看起来整形器增加了相当大的延迟，但事实并非如此。给定一个准确描述流量的有效 TSpec，整形将在整形点引起很少的额外实际延迟（并且根本不会影响延迟界限）。此外，在正常情况下，整形不会导致任何数据丢失。
但是，（通常在合并或分支点），TSpec 可能会小于实际流量。如果发生这种情况，整形将导致在整形点形成一个大队列，这既会导致大量额外的延迟，又会迫使某些数据包被视为不合格。这种情况使得令人不快的拒绝服务攻击成为可能，其中通过尽力而为服务成功接收流的流量的接收器被请求保留流的新接收器抢占，但 TSpec 和 RSpec 不足。流的流量现在将受到监管并可能重新调整。如果选择监管功能来丢弃数据包，则尽力而为的接收器将停止接收流量。出于这个原因，在正常情况下，监管者只是将不合格的数据包视为尽力而为（如果实施了标记，则对其进行标记）。虽然这可以防止拒绝服务，但错误的 TSpec 仍然可能导致排队延迟增加。
注意：为了最大限度地减少重新排序数据包的问题，当新数据包到达并且整形缓冲区已满时，整形点可能希望从整形队列的前面转发一个尽力而为的数据包。
读者还应该注意到，将数据包重新分类为尽力而为（而不是丢弃数据包）也可以更容易地支持弹性流。他们可以保留一个适度的令牌桶，当他们的流量超过令牌桶时，将尽最大努力发送多余的流量。
一个相关的问题是，在所有网络元素中，大于网络元素的 MTU 的数据包必须被认为是不合格的，并且应该被归类为尽力而为（然后将根据网络元素对尽力而为流量的处理进行分段或丢弃）。[再一次，如果标记可用，这些重新分类的数据包应该被标记。]
TSpec 是根据以下规则排序的。
如果 (1) TSpec A 的令牌率 r 和桶深度 b 都大于或等于 TSpec B 的，则 TSpec A 是 TSpec B 的替代品（“一样好或更好”）；(2) TSpec A 中的峰值速率 p 至少与 TSpec B 中的一样大；(3) TSpec A 的最小监管单元 m 至少与 TSpec B 的一样小；(4) TSpec A 的最大数据包大小 M 至少与 TSpec B 的一样大。
如果 (1) TSpec A 的令牌率 r 和桶深度 b 都小于或等于 TSpec B (2) TSpec A 中的峰值速率 p 至少与 TSpec B 中的峰值速率一样小；(3) TSpec A 的最小监管单元 m 至少与 TSpec B 的一样大；(4) TSpec A 的最大数据包大小 M 至少与 TSpec B 的一样小。
一个合并的 TSpec 可以在一组 TSpec 上计算，采用 (1) 最大令牌桶速率，(2) 最大桶大小，(3) 最大峰值速率，(4) 最小最小监管单元，和 (5 ) 集合中所有成员的最小最大数据包大小。这种“合并”一词的使用类似于 RSVP 协议 [10] 中的使用；合并的 TSpec 足以描述来自任何一个组成 TSpec 的流量。
通过计算 (1) 令牌桶速率的总和，(2) 桶大小的总和，(3) 峰值速率的总和，(4) 最小的最小值，可以在一组 TSpec 上计算求和的 TSpec监管单元，以及 (5) 最大数据包大小参数。
最不常见的 TSpec 是足以描述一组流量中任何一个流量的 TSpec。可以通过以下计算在一组 TSpec 上计算最不常见的 TSpec：(1) 最大令牌桶速率，(2) 最大桶大小，(3) 最大峰值速率，(4) 最小最小监管单元，以及(5) 集合中所有成员最大的最大数据包大小。
两个 TSpec 的最小值根据是否可以订购 TSpec 而有所不同。如果一个 TSpec 小于另一个 TSpec，则较小的 TSpec 是最小值。否则，通过比较两个 TSpec 中各自的值并选择 (1) 较小的令牌桶速率，(2) 较大的令牌桶大小 (3) 较小的峰值速率，(4)更小的最小监管单元，以及 (5) 更小的最大数据包大小。
RSpec 以与 TSpecs 类似的方式合并，即通过采用最大速率 R 和最小弹性 S 将一组 RSpecs 合并到单个 RSpec 中。更准确地说，如果值 RSpec A 是 RSpec B 的替代品RSpec A中预留服务速率R的值大于或等于RSpec B中的值，RSpec A中的slack值S小于或等于RSpec B中的值。
每个网元接收一个形式为（TSpec，RSpec）的服务请求，其中RSpec的形式为（Rin，Sin）。网络元素处理此请求并执行以下两种操作之一：
A. 它接受请求并返回形式为 (Rout, Sout) 的新 Rspec；
B. 它拒绝该请求。
生成新 RSpec 的处理规则由延迟约束控制：
Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin，其中 Ctoti 是当前元素 i 上游并包括当前元素 i 的所有网络元素的误差项 C 的累积和。换句话说，只要满足上述不等式，该元素消耗 (Sin – Sout) 的 slack 并且可以使用它来降低其预留水平。Rin 和 Rout 也必须满足约束：
r <= Rout <= Rin。当多个 RSpec，每一个的速率为 Rj，j=1,2…，要在一个分割点合并时，Rout 的值是所有速率 Rj 中的最大值，Sout 的值是所有速率中的最小值弹性项 Sj。
注意：上面描述的各种 TSpec 功能由希望组合 TSpec 的应用程序使用。然而，重要的是要观察到，实际预留的属性是通过将 TSpec 与 RSpec 速率 (R) 相结合来确定的。
由于保证预留同时需要TSpec和RSpec速率，RSVP中的共享预留存在一些难题，特别是在两个或多个源流相遇的情况下。在汇合点的上游，希望减少 TSpec 和 RSpec 以仅使用单个源流量所需的带宽和缓冲。（事实上，如果发送方通过低带宽链路进行传输，则可能有必要）。
但是，RSpec 的速率被设置为实现特定的延迟限制（并且不仅仅是 TSpec 的函数），因此更改 RSpec 可能会导致预留无法满足接收器的延迟要求。同时，不调整 RSpec 速率意味着只要特定链路上的可用带宽小于接收器请求的速率 R，使用保证服务的“共享”RSVP 预留就会失败，即使带宽足以支持发件人实际使用该链接。目前，此限制在使用 RSVP 保证服务时是一个未解决的问题。
本节不按特定顺序讨论一些重要的实现问题。
需要注意的是，单个子网是网络元素，路由器和子网都必须支持保证服务模型才能实现保证服务。由于子网通常不能使用基于 IP 的协议协商服务，作为提供有保障服务的一部分，路由器必须充当它们所连接的子网的代理。
在某些情况下，这种代理服务会很容易。例如，在上游节点上由 WFQ 调度器管理的租用线路上，proxy 只需保证所有流的 RSpec 速率之和不超过线路的带宽，并且需要通告基于速率的和非链路的基于速率的延迟，作为 C 和 D 的值。
在其他情况下，此代理服务会很复杂。例如，在 ATM 网络中，可能需要为流建立一个 ATM VC 并计算该 VC 的 C 和 D 项。读者可能会观察到，保证服务使用的令牌桶和峰值速率直接映射到 ATM 可变比特率流量的 Q.2931 QoS 参数的持续信元速率、突发大小和峰值信元速率。
数据包不会丢失的保证是通过将路由器缓冲区空间 B 设置为等于令牌桶 b 加上一些错误项（如下所述）来获得的。
与子网相关的另一个问题是 TSpec 的令牌桶速率测量 IP 流量，并且不（也不能）考虑链接级别的标头。因此子网网络元素必须调整速率和可能的存储桶大小以考虑添加链路级标头。隧道还必须考虑它们添加的额外 IP 标头。
对于数据包网络，通常可以通过将速率和桶大小除以最小监管单元来计算最大报头速率。对于进行内部分段的网络，例如 ATM，计算可能更复杂，因为必须考虑每个分段的开销和由于数据包大小和分段大小之间的不匹配而导致的任何浪费（传输的填充字节）。例如，由 ATM AAL5 加上 ATM 分段和重组强加的额外数据速率的保守估计是
((r/48)*5)+((r/m)*(8+52))它表示划分为 48 字节信元的速率乘以 5 字节 ATM 报头，加上最大数据包速率 (r/m) 乘以 8 字节 AAL5 报头的成本加上 ATM 可以浪费的最大空间数据包的分段（这是在一个包含一个字节的单元中浪费的 52 个字节）。但是这个估计可能非常高，特别是如果 m 很小，因为 ATM 浪费通常远小于 52 字节。（应该警告 ATM 实现者，在为呼叫建立设置 VC 参数时，令牌桶也可能必须进行缩放，并且该示例不考虑诸如 RFC 1483 中指定的封装所产生的开销）。
为了确保不丢失，网络元素必须为突发分配一些缓冲。如果每一跳都完美地实现了流体模型，那么这个缓冲就是 b（令牌桶大小）。然而，正如前面关于整形的讨论中所指出的，实现是近似值，我们预计流量在通过网络时会变得更加突发。然而，与整形一样，处理突发性所需的缓冲量受 b+Csum+Dsum*R 的限制。如果考虑到峰值速率，则可以进一步降低到
M + (b-M)(p-X)/(p-r) + (Csum/R + Dsum)X其中，如果 (b-M)/(p-r) 小于 Csum/R+Dsum，则 X 设置为 r，如果 (b-M)/(p-r) 大于或等于 Csum/R+Dsum 且 p>R，则 X 为 R；否则，X 设置为 p。这种减少是因为峰值速率限制了突发 b 可以放置在网络中的速率。相反，如果网络元素返回非零弹性项 Sout，则通过将 Sout 添加到 Dsum 来增加缓冲区需求。
虽然鼓励发送应用程序设置峰值速率参数并且需要整形点以符合它，但出于计算缓冲区需求和端到端延迟的目的忽略峰值速率总是可以接受的。结果只是高估了缓冲和延迟。如上所述，如果峰值速率未知（因此可能无限），则所需的缓冲为 b+Csum+Dsum*R。没有峰值速率的端到端延迟为 b/R+Ctot/R+Dtot。
每个网络元素的参数 D 应该设置为通过网络元素的最大数据包传输延迟变化（与速率和桶大小无关）。例如，在一个简单的路由器中，可以计算数据包通过输入接口到达处理器所需的最坏情况和最佳情况时间之间的差异，并将其添加到可能发生的任何变化中采取从处理器到出站链路调度程序（假设排队方案正常工作）。
对于数据包环境中的加权公平排队，D 设置为链路 MTU 除以链路带宽，以考虑数据包在最大大小的数据包开始传输时到达的可能性，并且到达的数据包应该具有在最大大小的数据包之前离开。对于基于帧的时隙系统（例如 Stop and Go 队列），D 是数据包在获得传输机会之前可能必须等待的最大时隙数。
请注意，多播可能会使确定 D 变得更加困难。在许多子网中，例如 ATM，子网的属性可能取决于从多播发送方到接收方的路径。有许多可能的方法来解决这个问题。一种是为整个子网选择一个有代表性的延迟，并将 D 设置为与该延迟的（非负）差异。另一个是估计子网出口点的子网属性，因为出口点可能最适合计算其从源头开始的路径的属性。
注意：重要的是要注意，关于子网如何确定其属性并没有固定的规则集，并且每种子网技术都必须开发自己的一组程序来准确计算 C 和 D 以及弹性值。
D 旨在区别于通过网络元素的延迟。延迟是通过设备的最短时间（光纤中的光速延迟或将数据包通过路由器所需的绝对最短时间），而参数 D 旨在限制非基于速率的延迟的可变性。在实践中，这种区别有时是任意的（延迟可能很小）——在这种情况下，将延迟与 D 结合起来并将任何延迟宣传为零是完全合理的。
注意：在这个方案中，为了完全保证一个数据包可能经历的最大延迟，这个服务的用户需要知道排队延迟（由 C 和 D 提供）和延迟。该服务不通告延迟，但它是一个通用特征参数（如 [8] 中指定的那样通告）。
但是，即使没有公布延迟，仍然可以使用此服务。最简单的方法是测量接收到的第一个数据包所经历的延迟（或前几个数据包的最小延迟），并将此延迟值视为延迟的上限。
参数 C 是由于特定实现如何偏离严格的逐位服务的变幻莫测而导致的数据积压。因此，例如，对于数据包化加权公平队列，C 设置为 M 以考虑分组化效果。
如果网络元素使用一定量的弹性 Si 来减少它为特定流 i 保留的资源量，则值 Si 应该存储在网络元素中。随后，如果接收到流 i 的保留刷新，则网络元素必须使用相同的弹性 Si 而无需任何进一步的计算。这保证了预订过程的一致性。
作为使用弹性项的示例，考虑所需的端到端延迟 Dreq 大于流体流动系统的最大延迟的情况。后者通过在流体延迟公式中设置 R=r 得到（为了稳定，R>=r 必须为真），由下式给出
b/r + Ctot/r + Dtot。
在这种情况下，弹性项是
S = Dreq - (b/r + Ctot/r + Dtot)。
网络元素可以使用弹性项来调整它们的本地保留，以便它们可以接纳否则会被拒绝的流。可以在内部区分延迟和速率保证的中间网络元素处的网络元素现在可以利用该信息来降低分配给该流的资源量。例如，通过采用一定数量的 slack s <= S，RCSD 调度器 [5] 可以将分配给流的本地延迟界限 d 增加到 d+s。给定一个 RSpec，(Rin, Sin)，它可以通过设置 Rout = Rin 和 Sout = Sin – s 来实现。
类似地，使用 WFQ 调度器的网络元素可以通过使用 RSpec 中的一些弹性来减少其从 Rin 到 Rout 的本地预留。这可以通过使用上一节中给出的转换规则来完成，确保减少的预留级别不会增加整体端到端延迟。
当源的流量符合 TSpec 时，元素的调度算法和准入控制算法必须确保永远不会违反延迟界限并且不会丢失数据包。此外，该元素必须确保行为不端的流不会影响提供给其他流的服务。鼓励供应商正式证明他们的实现是流体模型的近似。
存在几种近似流体模型的算法和实现。它们包括加权公平队列 (Weighted Fair Queueing，WFQ) [2]、Jitter-EDD [3]、虚拟时钟 [4] 和 IBM [5] 提出的方案。一个很好的理论展示表明这些方案是一大类算法的一部分，可以在 [6] 中找到。
考虑一个不能容忍任何丢失或延迟数据包的应用程序。它使用通告的值 Ctot 和 Dtot 以及流的 TSpec 来计算速率为 R 的服务请求产生的延迟界限。假设 R < p，然后将其回放点设置为 [(bM)/R*(pR )/(pr)]+(M+Ctot)/R+Dtot。
本备忘录讨论了如何滥用此服务来允许拒绝服务攻击。定义的服务不允许拒绝服务（尽管在某些情况下服务可能会降级）。
参考文献 [9] 中详细说明了保证服务与 RSVP 资源预留设置协议的结合使用。本文档提供了支持需要保证服务的应用程序所需的 RSVP FLOWSPEC、SENDER_TSPEC 和 ADSPEC 对象的格式，并提供了有关 RSVP 如何处理这些对象的信息。RSVP 协议本身在参考文献 [10] 中有详细说明。
[1] Shenker, S., and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, September 1997.[2] A. Demers, S. Keshav and S. Shenker, "Analysis and Simulation of a Fair Queueing Algorithm," in Internetworking: Research and Experience, Vol 1, No. 1., pp. 3-26.[3] L. Zhang, "Virtual Clock: A New Traffic Control Algorithm for Packet Switching Networks," in Proc. ACM SIGCOMM '90, pp. 19-29.[4] D. Verma, H. Zhang, and D. Ferrari, "Guaranteeing Delay Jitter Bounds in Packet Switching Networks," in Proc. Tricomm '91.[5] L. Georgiadis, R. Guerin, V. Peris, and K. N. Sivarajan, "Efficient Network QoS Provisioning Based on per Node Traffic Shaping," IBM Research Report No. RC-20064.[6] P. Goyal, S.S. Lam and H.M. Vin, "Determining End-to-End Delay Bounds in Heterogeneous Networks," in Proc. 5th Intl. Workshop on Network and Operating System Support for Digital Audio and Video, April 1995.[7] A.K.J. Parekh, A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks, MIT Laboratory for Information and Decision Systems, Report LIDS-TH-2089, February 1992.[8] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.[9] Wroclawski, J., "Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.[10] Braden, R., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.