Network Working Group S. Jackowski
Request for Comments: 2688 Deterministic Networks
Category: Standards Track D. Putzolu
Intel Architecture Labs
E. Crawley
Argon Networks
B. Davie
Cisco Systems
September 1999
Network Working Group S. Jackowski
Request for Comments: 2688 Deterministic Networks
Category: Standards Track D. Putzolu
Intel Architecture Labs
E. Crawley
Argon Networks
B. Davie
Cisco Systems
September 1999
Integrated Services Mappings for Low Speed Networks
低速网络的综合业务映射
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
A set of companion documents describe an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links [1, 2, 3, 4]. The main components of the architecture are: a set of real-time encapsulation formats for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
一组配套文件描述了通过低比特率链路（如调制解调器线路、ISDN B信道和子T1链路）提供综合业务的体系结构[1、2、3、4]。该体系结构的主要组成部分包括：异步和同步低比特率链路的一组实时封装格式、针对实时流优化的报头压缩体系结构、路由器之间（或主机与路由器之间）使用的协商协议元素，以及应用程序用于允许进行此协商的公告协议。
This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load [5] and guaranteed [6] services. The approach takes the form of a set of guidelines and considerations for implementing these services, along with evaluation criteria for elements providing these services.
本文件定义了低比特率链路的IETF集成服务的服务映射，特别是受控负载[5]和保证[6]服务。该方法采用了一套实施这些服务的指南和考虑因素，以及提供这些服务的要素的评估标准。
In addition to the "best-effort" services the Internet is well-known for, other types of services ("integrated services") are being developed and deployed in the Internet. These services support special handling of traffic based on bandwidth, latency, and other requirements that cannot usually be met using "best-effort" service.
除了因特网众所周知的“尽力而为”的服务外，还在因特网上开发和部署其他类型的服务（“综合服务”）。这些服务支持基于带宽、延迟和其他使用“尽力而为”服务通常无法满足的要求对流量进行特殊处理。
This document defines the mapping of integrated services "controlled load" [5] and "guaranteed" [6] services on to low-bandwidth links. The architecture and mechanisms used to implement these services on such links are defined in a set of companion documents. The mechanisms defined in these documents include both compression of flows (for bandwidth savings) [4,10] and a set of extensions to the PPP protocol which permit fragmentation [2] or suspension [3] of large packets in favor of packets from flows with more stringent service requirements.
本文档定义了集成服务“受控负载”[5]和“保证”[6]服务到低带宽链路的映射。用于在此类链接上实现这些服务的体系结构和机制在一组配套文档中定义。这些文件中定义的机制包括流压缩（为了节省带宽）[4,10]和PPP协议的一组扩展，这些扩展允许大数据包的分段[2]或暂停[3]，以利于来自具有更严格服务要求的流的数据包。
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 [11].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[11]中所述进行解释。
Unlike other link layers, the links referred to in this document operate only over low speed point to point connections. Examples of the kinds of links addressed here include dial-up lines, ISDN channels, and low-speed (1.5Mbps or less) leased lines. Such links can occur at different positions within the end-to-end path:
与其他链路层不同，本文档中提到的链路仅在低速点对点连接上运行。此处所述链路类型的示例包括拨号线路、ISDN信道和低速（1.5Mbps或更低）租用线路。这种链接可以出现在端到端路径中的不同位置：
- host to directly connected host. - host to/from network access device (router or switch). - Edge device (subnet router or switch) to/from router or switch. - In rare circumstances, a link from backbone router to backbone router.
- 主机到直接连接的主机。-主机到/从网络访问设备（路由器或交换机）。-与路由器或交换机之间的边缘设备（子网路由器或交换机）。-在极少数情况下，从骨干路由器到骨干路由器的链路。
These links often represent the first or last wide area hop in a true end to end service. Note that these links may be the most bandwidth constrained along the path between two hosts.
这些链路通常表示真正的端到端服务中的第一个或最后一个广域跳转。请注意，沿两台主机之间的路径，这些链路可能是带宽限制最多的链路。
The services utilized in mapping integrated services to these links are only provided if both endpoints on the link support the architecture and mechanisms referenced above. Support for these mechanisms is determined during the PPP negotiation. The non-shared
仅当链接上的两个端点都支持上述体系结构和机制时，才会提供将集成服务映射到这些链接中所使用的服务。对这些机制的支持在PPP谈判期间确定。非共享
nature of these links, along with the fact that point-to-point links are typically dual simplex (i.e., the send and receive channels are separate) allows all admission control decisions to be made locally.
这些链路的性质，加上点到点链路通常是双单工（即，发送和接收信道是分开的）这一事实，允许在本地做出所有接纳控制决策。
As described in [2] and [3], for systems that can exert real time control of their transmission at a finer grain than entire HDLC frames, the suspend/resume approach optimizes the available bandwidth by minimizing header overhead associated with MLPPP pre-fragmentation and can provide better delay. However, this comes at the expense of preparing all outgoing data and scanning all incoming data for suspend/resume control information. The fragmentation approach can be implemented without additional scanning of the data stream (beyond bit-/byte-stuffing, which may be in hardware) and is applicable to systems which provide only frame-oriented transmission control. Choice of suspend/resume versus fragmentation should be made based on the level of transmission control, the element's capability to handle the HDLC-like framing described in [2], and the system overhead associated with byte by byte scanning (required by suspend/resume).
如[2]和[3]中所述，对于能够以比整个HDLC帧更精细的粒度对其传输进行实时控制的系统，挂起/恢复方法通过最小化与MLPPP预分段相关的报头开销来优化可用带宽，并可以提供更好的延迟。但是，这是以准备所有传出数据和扫描所有传入数据以获取挂起/恢复控制信息为代价的。分段方法可以在不额外扫描数据流的情况下实现（比特/字节填充之外，可能在硬件中），并且适用于仅提供面向帧的传输控制的系统。应根据传输控制水平、元件处理[2]中所述类似HDLC的帧的能力以及与逐字节扫描相关的系统开销（暂停/恢复要求），选择暂停/恢复还是分段。
To provide controlled load or guaranteed service with the suspend/resume approach, when a packet for an admitted flow (QoS packet) arrives during transmission of a best effort packet and continued transmission of the best effort packet would violate delay constraints of the QoS service flows, the best effort packet is preempted, the QoS packet/fragments are added to the transmission, and the best effort packet transmission is then resumed: usually all in one transmission. The receiving station separates the best effort packet from the embedded QoS packet's fragments. It is also conceivable that one QoS flow's packet might suspend another flow's packet if the delivery deadline of the new packet is earlier than the current packet.
为了使用挂起/恢复方法提供受控负载或保证服务，当在尽力而为数据包的传输期间用于接纳流的数据包（QoS数据包）到达并且尽力而为数据包的继续传输将违反QoS服务流的延迟约束时，尽力而为数据包被抢占，QoS数据包/片段被添加到传输中，然后恢复尽力而为的数据包传输：通常是一次传输。接收站将尽力而为的数据包从嵌入的QoS数据包的片段中分离出来。还可以想象，如果新分组的传递截止时间早于当前分组，则一个QoS流的分组可能会挂起另一个流的分组。
For systems which use fragmentation, any packets longer than the maximum tolerable delay for packets from enhanced service flows are fragmented prior to transmission so that a short packet for another flow can be interleaved between fragments of a larger packet and still meet the transmission deadline for the flow requiring enhanced services.
对于使用分段的系统，任何长于来自增强服务流的分组的最大可容忍延迟的分组在传输之前被分段，以便另一个流的短分组可以在较大分组的片段之间交错，并且仍然满足需要增强服务的流的传输截止时间。
Note that the fragmentation discussed in this document refers to multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications as described in [2], not IP or other layer 3 fragmentation. MLPPP fragmentation is local to the PPP link, and does not affect end-to-end (IP) MTU.
请注意，本文档中讨论的碎片是指[2]中所述的多链路PPP（MLPPP）碎片和相关MCMLPPP修改，而不是IP或其他第3层碎片。MLPPP碎片是PPP链路的本地碎片，不会影响端到端（IP）MTU。
A router which provides Controlled Load or Guaranteed Service over a low speed serial link needs to have some notion of the "acceptable delay" for packets that belong to int-serv flows. If using fragmentation, a router needs to know what size to fragment packets to; if using suspend/resume, it needs to know when it is appropriate to suspend one packet to meet the delay goals of another.
通过低速串行链路提供受控负载或保证服务的路由器需要对属于int-serv流的数据包具有“可接受延迟”的概念。如果使用分段，路由器需要知道将数据包分段到什么大小；如果使用suspend/resume，它需要知道何时适合挂起一个数据包以满足另一个数据包的延迟目标。
Unfortunately, there is no hard and fast way for a single delay bound to be determined for a particular flow; while the end-points of a flow have enough information to determine acceptable end-to-end delay bounds and to make reservation requests of the network to meet those bounds, they do not communicate a "per-hop" delay to routers.
不幸的是，对于一个特定的流，没有硬性的方法来确定一个单一的延迟；虽然流的端点具有足够的信息来确定可接受的端到端延迟边界，并发出网络的保留请求以满足这些边界，但它们不向路由器传递“每跳”延迟。
In the case of Guaranteed Service [6], one approach is to let the network operator configure parameters on the router that will directly affect its delay performance. We observe that guaranteed service allows routers to deviate from the ideal fluid flow model and to advertise the extent of the deviation using two error terms C and D, the rate-dependent and rate-independent error terms, defined in [6]. A network operator can configure parameters of the low speed link in such a way that D is set to a value of her choice.
在保证服务[6]的情况下，一种方法是让网络运营商在路由器上配置将直接影响其延迟性能的参数。我们观察到，保证服务允许路由器偏离理想流体流动模型，并使用[6]中定义的两个误差项C和D（与速率相关和与速率无关的误差项）公布偏差程度。网络运营商可以配置低速链路的参数，使D设置为她选择的值。
If link-level fragmentation is used, the router controlling a low-speed link can be configured with a certain fragment size. This will enable a component of the error term D to be calculated based on the time to send one fragment over the link. (Note that D may have other components such as the speed of light delay over the link.) Details of the calculation of D are described below. Similarly, if suspend/resume is used, the router may be configured with a delay parameter, which would enable it to decide when it was appropriate to suspend a packet.
如果使用链路级分段，则控制低速链路的路由器可以配置特定的分段大小。这将使错误项D的一个组成部分能够基于通过链路发送一个片段的时间来计算。（请注意，D可能具有其他组件，例如链路上的光速延迟。）D的计算细节如下所述。类似地，如果使用挂起/恢复，则路由器可配置有延迟参数，该参数将使其能够决定何时适合挂起分组。
For Controlled Load, there are no error terms, and the router must decide how best to meet the requirements of the admitted reservations using only the information in their TSpecs. Since the definition of Controlled Load states that a CL flow with Tspec rate r should receive treatment similar to an unloaded network of capacity r, CL packets should not generally experience end-to-end delays significantly greater than b/r + propagation delays. Clearly a router connected to a low speed link should not introduce a delay greater than b/r due to transmission of other fragments; ideally it should introduce substantially less delay than b/r, since other hops on the end-to-end path may introduce delay as well. However, this may be difficult for flows with very small values of b.
对于受控负载，没有错误项，路由器必须决定如何最好地满足允许的保留的要求，只使用其TSPEC中的信息。由于受控负载的定义规定，具有Tspec速率r的CL流应接受类似于容量r的空载网络的处理，因此CL数据包通常不应经历明显大于b/r+传播延迟的端到端延迟。显然，连接到低速链路的路由器不应由于其他片段的传输而引入大于b/r的延迟；理想情况下，它应该引入比b/r小得多的延迟，因为端到端路径上的其他跳也可能引入延迟。然而，对于b值非常小的流来说，这可能很困难。
It is expected that implementers will make their own tradeoffs as to how low to make the delay for Controlled Load flows. Similarly, it may not be possible or desirable to configure the parameters affecting D to arbitrarily small values, since there is a cost in overhead in fragmenting packets to very small sizes. Conversely, if D is too large, some applications may find that they cannot make a reservation that will meet their delay objectives.
预计实现者将自行权衡控制负载流的延迟程度。类似地，可能不可能或不希望将影响D的参数配置为任意小的值，因为在将分组分段为非常小的大小时存在开销成本。相反，如果D太大，一些应用程序可能会发现他们无法进行满足延迟目标的预订。
For the remainder of this document, we assume that a router has some notion of the acceptable delay that it may introduce before beginning transmission of a packet. This delay is in addition to any delay that a packet might be subjected to as a result of the "ideal" queuing algorithm that the router uses to schedule packets.
对于本文档的其余部分，我们假设路由器在开始传输数据包之前可能会引入一些可接受延迟的概念。此延迟是由于路由器用于调度数据包的“理想”排队算法而导致的数据包可能受到的任何延迟之外的延迟。
Supporting integrated services over PPP links which implement MCML or RTF can be accomplished in several ways. Guidelines for mapping these services to PPP links and to the classes provided by the suspend/resume and fragmentation mechanisms are presented below. Note that these guidelines assume that some sort of signaling protocol is used to indicate desired quality of service to both the sender and receiver of a flow over a PPP link.
通过实现MCML或RTF的PPP链路支持集成服务可以通过多种方式实现。下面给出了将这些服务映射到PPP链接以及由挂起/恢复和分段机制提供的类的指南。注意，这些指南假设使用某种信令协议来指示通过PPP链路的流的发送方和接收方所需的服务质量。
A relatively simple method of class mapping that MAY be used is one where class values correspond to predefined levels of service. In this arrangement, all admitted flows are grouped into one of several buckets, where each bucket roughly corresponds to the level of service desired for the flows placed in it. An example set of mappings appears below:
可以使用一种相对简单的类映射方法，其中类值对应于预定义的服务级别。在这种布置中，所有允许的流量都被分组到几个桶中的一个，其中每个桶大致对应于放置在其中的流量所需的服务水平。下面显示了一组映射示例：
MCML Short MCML Long RTF Service
短MCML长RTF服务
0b00 0b0000 0b000 Best Effort NA 0b0001 0b001 Reserved 0b01 0b0010 0b010 Delay Sensitive, no bound NA 0b0011 0b011 Reserved NA 0b0100 0b100 Reserved 0b10 0b0101 0b101 Delay Sensitive, 500ms bound NA 0b0110 0b110 Delay Sensitive, 250ms bound 0b11 0b0111 0b111 Network Control
0b00 0b0000 0b000尽力而为NA 0b0001 0b001保留0b01 0b0010 0b010延迟敏感，无绑定NA 0b0011 0b011保留NA 0b0100 0b100保留0b10 0b0101 0b101延迟敏感，500ms绑定NA 0b0110 0b110延迟敏感，250ms绑定0b11 0b0111 0b111网络控制
Table 1: Example Mappings of Classes to Services
表1：类到服务的映射示例
Note that MCML has two formats, short sequence numbers, and long sequence numbers, that allow for 2 and 4 bits of class identification. RTF allows for 3 bits of class identification in all formats.
注意，MCML有两种格式，短序列号和长序列号，允许2位和4位的类标识。RTF允许所有格式的3位类标识。
Using a default-mapping method of assigning classes to flows in a fixed fashion comes with certain limitations. In particular, all flows which fall within a particular bucket (are assigned to a particular class) will be scheduled against each other at the granularity of packets, rather than at the finer grained level of fragments. This can result in overly conservative admission control when the number of available classes is small such as in MCML short sequence number format.
使用默认的映射方法将类以固定方式分配给流有一定的限制。特别是，属于特定bucket（分配给特定类）的所有流将在数据包的粒度上相互调度，而不是在更细粒度的片段级别上调度。当可用类的数量很小时，例如在MCML短序列号格式中，这可能导致过度保守的接纳控制。
In the case where fewer reservations are expected than the total number of classes negotiated for a PPP link, it is possible to assign individual flows to fixed class numbers. This assignment is useful in the case where the protocol identifier associated with one or more flows is known at LCP negotiation time and the bandwidth of the connection is relatively small. If these conditions hold true, then for those flows that are known, a specific class can optionally be assigned to them and the prefix elision PPP option [2] can be used for those classes to achieve a small bandwidth savings.
如果预计预订数量少于PPP链路协商的总类数，则可以将单个流分配给固定类数。在与一个或多个流相关联的协议标识符在LCP协商时已知并且连接的带宽相对较小的情况下，该分配是有用的。如果这些条件成立，那么对于那些已知的流，可以选择为它们分配特定的类，并且前缀省略PPP选项[2]可以用于这些类以实现小的带宽节省。
In the case where predefined class mappings are not satisfactory, an implementer MAY map class values to individual packets rather than assigning flows to fixed classes. This can be done due to the fact that the classes that MCML and RTF provide can be viewed purely as PPP-specific segmentation/fragmentation mechanisms. That is, while the class number MUST remain constant on an intra-packet basis, it MAY vary on an inter-packet basis for all flows transiting a PPP link. Actual assignment of particular flows to fixed classes is unnecessary, as the class numbers are NOT REQUIRED to have any meaning other than in the context of identifying the membership of fragments/segments as part of a single packet. This point is sufficiently important that an example is provided below.
在预定义类映射不令人满意的情况下，实现者可以将类值映射到各个包，而不是将流分配给固定类。这可以做到，因为MCML和RTF提供的类可以纯粹看作PPP特定的分段/分段机制。也就是说，尽管类号必须在分组内保持不变，但对于通过PPP链路的所有流，它可能在分组间变化。将特定流实际分配给固定类是不必要的，因为除了在将片段/段的成员身份识别为单个数据包的一部分的上下文中，类编号不需要具有任何意义。这一点非常重要，下面提供一个例子。
Consider a PPP link using the MCML short sequence number fragment format (that is, four classes are provided). Assume that in addition to carrying best effort traffic, this link is carrying five guaranteed service flows, A, B, C, D, and E. Further assume that the link capacity is 100kbit/s and the latency is 100ms. Finally, assume the BE traffic is sufficient to keep the pipe full at all times and that GS flows A-E are each 10kbit/s and all have delay bounds of 145ms.
考虑使用MCML短序列号片段格式（即，提供了四个类）的PPP链接。假设除了承载尽力而为的流量外，该链路还承载五个保证服务流，即A、B、C、D和E。进一步假设链路容量为100kbit/s，延迟为100ms。最后，假设BE流量足以使管道始终充满，并且GS流量A-E每10kbit/s，所有流量的延迟范围均为145ms。
Time(ms) Action 0 BE traffic is queued up 0 2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...) 8 2kbit fragment from BE sent, cls 0 (10kbit BE packet done) 9 8kbit packet from flow A arrives 10 2kbit fragment from A sent, cls 1 (8kbit flow A packet start) 11 8kbit packet from flow B arrives 12 2kbit fragment from B sent, cls 2 (8kbit flow B packet start) 13 8kbit packets from flows C, D, and E arrive 14 2kbit fragment from C sent, cls 3 (8kbit flow C packet start) 16 2kbit fragment from D sent, cls 0 (8kbit flow D packet start) 18 2kbit fragment from A sent, cls 1 20 2kbit fragment from B sent, cls 2 22 2kbit fragment from A sent, cls 1 24 2kbit fragment from A sent, cls 1 (8kbit flow A packet done) 26 2kbit fragment from E sent, cls 1 (8kbit flow E packet start) 27 8kbit packet from flow A arrives 28 2kbit fragment from B sent, cls 2 30 2kbit fragment from C sent, cls 3 32 2kbit fragment from E sent, cls 1 34 2kbit fragment from B sent, cls 2 (8kbit flow B packet done) 36 2kbit fragment from E sent, cls 1 38 2kbit fragment flow A sent, cls 2 (8kbit flow A packet start) (etc.)
时间（ms）动作0 BE通信排队从发送的10kbit数据包0 2kbit片段，从发送的cls 0（…）8 2kbit片段，从流A的cls 0（10kbit BE数据包完成）9 8kbit数据包到达发送的10 2kbit片段，从流B的cls 1（8kbit流A数据包开始）11 8kbit数据包到达发送的12 2kbit片段，cls 2（8kbit流B数据包开始）来自流C、D和E的13个8kbit数据包到达14个发送自C的2kbit片段，cls 3（8kbit流C数据包开始）16个发送自D的2kbit片段，cls 0（8kbit流D数据包开始）发送的18 2kbit片段，发送的B的20 2kbit片段，发送的22 2kbit片段，发送的24 2kbit片段，发送的1（8kbit流A数据包完成）26 2kbit片段，发送的1（8kbit流E数据包开始）来自流A的27 8kbit数据包到达B发送的28 2kbit片段，来自C发送的cls 2 30 2kbit片段，来自E发送的cls 3 32 2kbit片段，来自B发送的cls 1 34 2kbit片段，来自E发送的cls 2（8kbit流B数据包完成）36 2kbit片段，来自A发送的cls 1 38 2kbit片段，来自cls 2（8kbit流A数据包开始）（等等）
This example shows several things. First, multiple flows MAY share the same class, particularly in the case where there are more flows than classes. More importantly, there is no reason that a particular flow must be assigned to a fixed class - the only requirement is that each packet, when fragmented, MUST have the same class value assigned to all fragments. Beyond this requirement the link scheduler may assign individual to changing class numbers as necessary to meet reservation requirements.
这个例子展示了几个方面。首先，多个流可能共享同一个类，特别是在流多于类的情况下。更重要的是，没有理由必须将特定流分配给固定类-唯一的要求是，每个数据包在分段时，必须将相同的类值分配给所有分段。除此要求外，链路调度器还可以根据需要为更改的类号分配个人，以满足保留要求。
One suggestion to implementers of integrated services on MCML and RTF links using dynamic mappings is that all BE traffic SHOULD be logically separated from QoS traffic, and mapped to a fragmentable (MCML classes 0-3 in short sequence number fragment format, 0-15 in long sequence number fragment format) or suspendable (RTF classes 0- 6) class. Since BE traffic will in most implementations not be scheduled for transmission except when a link is empty (that is, no CL or GS traffic is ready for transmission), implementers MAY choose to make use of class number 0 for BE traffic.
对使用动态映射的MCML和RTF链路上的集成服务的实现者的一个建议是，所有BE流量都应该从QoS流量中逻辑分离，并映射到可分段（短序列号片段格式的MCML类0-3，长序列号片段格式的0-15）或可暂停（RTF类0-6）类。由于在大多数实现中，除非链路为空（即，没有CL或GS通信准备好传输），否则BE通信将不会被调度用于传输，因此实现者可以选择使用类号0来传输BE通信。
Treatment of non-conformant QoS traffic is largely determined by the appropriate service specifications, but the detailed implementation in the context of this draft allows for some flexibility. Policing of flows containing non-conformant traffic SHOULD always be done at the level of granularity of individual packets rather than at a finer grained level. In particular, in those cases where a network element scheduling flows for transmission needs to drop non-conformant traffic, it SHOULD drop entire packets rather than dropping individual fragments of packets belonging to non-conformant traffic. In those cases where a network element forwards non-conformant traffic when link bandwidth is available rather than dropping the traffic, the implementation SHOULD fragment packets of such traffic as if it were best effort traffic.
不一致QoS流量的处理在很大程度上取决于适当的服务规范，但本草案上下文中的详细实现允许一些灵活性。对包含不一致流量的流的监控应始终在单个数据包的粒度级别上进行，而不是在更细粒度的级别上进行。特别地，在用于传输的网络单元调度流需要丢弃非一致性业务的情况下，它应该丢弃整个分组，而不是丢弃属于非一致性业务的分组的单个片段。在链路带宽可用时网元转发非一致性流量而不是丢弃流量的情况下，实现应将此类流量的数据包分割为尽最大努力流量。
Whether BE and non-conformant traffic are treated differently in regards to transmission (e.g., BE is given priority access over non-conformant traffic to the link) or whether within each type of traffic special treatment is afforded to individual flows (e.g., WFQ, RED, etc.) is service dependent.
BE和非一致性业务是否在传输方面得到不同的处理（例如，BE优先于对链路的非一致性业务的访问），或者是否在每种类型的业务中对单个流（例如，WFQ、RED等）给予特殊处理取决于服务。
An important consideration in performing admission control for PPP links is reductions in effective link rate due to bit stuffing. Typical bit stuffing algorithms can result in as much as 20% additional overhead. Thus, admission control implementations for guaranteed service over links where bit stuffing is used SHOULD take the RSpec rate of all flows and multiply by 1.2, to account for the 20% overhead from bit stuffing, when determining whether a new flow can be admitted or not. Admission control implementations for controlled load reservations may use a similar algorithm using the TSpec peak rate or may attempt to measure the actual degree of expansion occurring on a link due to bit stuffing. This characterization can then be used to adjust the calculated remaining link capacity. Such measurements must be used cautiously, in that the degree of bit stuffing that occurs may vary significantly, both in an inter- and intra-flow fashion.
在对PPP链路执行接纳控制时，一个重要的考虑因素是由于比特填充而降低有效链路速率。典型的位填充算法可能导致高达20%的额外开销。因此，当确定是否可以接纳新的流时，在使用位填充的链路上保证服务的接纳控制实现应采用所有流的RSpec速率并乘以1.2，以考虑位填充的20%开销。用于受控负载预留的接纳控制实现可以使用使用TSpec峰值速率的类似算法，或者可以尝试测量由于比特填充而在链路上发生的实际扩展程度。然后可以使用该特征来调整计算的剩余链路容量。必须谨慎使用此类测量，因为发生的比特填充程度可能会在流间和流内发生显著变化。
Byte stuffing is also used on many PPP links, most frequently on POTS modems when using the v.42 protocol. Byte stuffing poses a difficult problem to admission control, particularly in the case of guaranteed service, due to its highly variable nature. In the worse case, byte stuffing can result in a doubling of frame sizes. As a consequence, a strict implementation of admission control for guaranteed load on
字节填充也用于许多PPP链路，在使用v.42协议时，最常用于POTS调制解调器。字节填充给准入控制带来了一个难题，特别是在保证服务的情况下，由于其高度可变的性质。在更糟糕的情况下，字节填充可能导致帧大小加倍。因此，必须严格执行许可控制，以保证服务器上的负载
byte stuffed PPP links SHOULD double the RSpec of link traffic in making flow admission decisions. As with bit stuffing, implementations of controlled load service admission control algorithms for links with byte stuffing MAY attempt to determine average packet expansion via observation or MAY use the theoretical worst case values.
在做出流量接纳决策时，字节填充的PPP链路应将链路流量的RSpec增加一倍。与比特填充一样，针对具有字节填充的链路的受控负载服务接纳控制算法的实现可以尝试通过观察来确定平均分组扩展，或者可以使用理论上的最坏情况值。
The architecture for providing integrated services over low bandwidth links uses several PPP options to negotiate link configuration as described in [4, 8, 10]. When deciding whether to admit a flow, admission control MUST compute the impact of the following on MTU size, rate, and fragment size:
通过低带宽链路提供综合服务的体系结构使用多个PPP选项协商链路配置，如[4,8,10]所述。在决定是否接纳流时，接纳控制必须计算以下因素对MTU大小、速率和碎片大小的影响：
Header compression: Van Jacobson or Casner-Jacobson [4,8,10]. Prefix Elision. CCP. Fragment header option used. Fragmentation versus suspend/resume approach.
头部压缩：Van Jacobson或Casner Jacobson[4,8,10]。前缀省略。CCP使用了片段头选项。分段与挂起/恢复方法。
If any of the compression options are implemented for the connection, the actual transmission rate, and thus the bandwidth required of the link, will be reduced by the compression method(s) used.
如果为连接实现了任何压缩选项，则实际传输速率以及链路所需的带宽将通过所使用的压缩方法降低。
Prefix elision can take advantage of mapping flows to MLPPP classes to elide prefixes which cannot be compressed at higher layers. By establishing agreement across the link, the sender may elide a prefix for a certain class of traffic and upon receiving packets in that class, the receiver can restore the prefix.
前缀省略可以利用将流映射到MLPPP类来省略不能在更高层压缩的前缀。通过在链路上建立协议，发送方可以省略某类业务的前缀，并且在接收到该类中的分组时，接收方可以恢复前缀。
Both compression gain and elision gain MUST be included as described in the admission control section below. Note that the ability to perform compression at higher layers (e.g. TCP or RTP/UDP) may depend on the provision of a hint by the sender, as described in [9].
压缩增益和省略增益都必须包括在下面的许可控制部分中。请注意，在更高层（如TCP或RTP/UDP）执行压缩的能力可能取决于发送方提供的提示，如[9]所述。
Admission control MUST decide whether to admit a flow based on rate and delay. Assume the following:
接纳控制必须根据速率和延迟决定是否接纳流。假设如下：
LinkRate is the rate of the link. MTU is the maximum transmission unit from a protocol. MRU is the maximum receive unit for a particular link. CMTU is the maximum size of the MTU after compression is applied. eMTU is the effective size at the link layer of an MTU-sized packet after link layer fragmentation and addition of the fragment headers. FRAG is the fragment size including MLPPP header/trailers.
LinkRate是链接的速率。MTU是协议的最大传输单位。MRU是特定链路的最大接收单位。CMTU是应用压缩后MTU的最大尺寸。eMTU是链路层分段和添加分段头之后，MTU大小的数据包在链路层的有效大小。FRAG是碎片大小，包括MLPPP头/拖车。
Header is the size of the header/trailers/framing for MLPPP/Fragments. pHeader is the additional header/framing overhead associated with suspend/resume. This should include FSE and worst case stuffing overhead. pDelay is the time take to suspend a packet already "in flight", e.g. due to the delay to empty the output FIFO. b is the bucket depth in bytes R is the requested Rate. Dlink is the fixed overhead delay for the link (Modem, DSU, speed-of-light, etc). eRate is the effective rate after compression and fragmentation.
Header是MLPPP/碎片的Header/拖车/框架的大小。pHeader是与挂起/恢复相关联的额外标头/帧开销。这应包括FSE和最坏情况下的填料开销。pDelay是指暂停已经“飞行”的数据包所需的时间，例如由于清空输出FIFO的延迟。b是以字节为单位的存储桶深度，R是请求的速率。Dlink是链路的固定开销延迟（调制解调器、DSU、光速等）。rate是压缩和碎片后的有效速率。
The Dlink term MAY be configured by an administrative tool once the network is installed; it may be determined by real-time measurement means; or it MAY be available from hardware during link setup and/or PPP negotiation. Refer to Appendix A for more considerations on PPP link characteristics and delays.
一旦安装了网络，就可以通过管理工具配置Dlink术语；可通过实时测量手段确定；或者，在链路设置和/或PPP协商期间，可以从硬件获得。关于PPP链路特性和延迟的更多注意事项，请参阅附录A。
Admission control MUST compute CMTU, eMTU, and eRate for Controlled Load Service, and it MUST compute CMTU, eMTU, eRate, and D for Guaranteed Service:
准入控制必须计算受控负载服务的CMTU、eMTU和Rate，必须计算保证服务的CMTU、eMTU、Rate和D：
To determine whether the requested rate is available, Admission Control MUST compute the effective rate of the request (eRate) - worst case - as follows:
为了确定请求的速率是否可用，接纳控制必须计算请求的有效速率（rate）-最坏情况-如下所示：
#_of_Fragments = CMTU div (FRAG-Header) [Integer divide] Last_Frag_Size = CMTU mod (FRAG-Header
#_碎片数量=CMTU div（碎片头）[整数除法]最后碎片大小=CMTU mod（碎片头
If Last_Frag_Size != 0
eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size + Header
Else
eMTU = (#_of_Fragments) * FRAG
If Last_Frag_Size != 0
eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size + Header
Else
eMTU = (#_of_Fragments) * FRAG
eRate = eMTU/CMTU * R [floating point divide]
eRate = eMTU/CMTU * R [floating point divide]
Admission control SHOULD compare the eRate of the request against the remaining bandwidth available to determine if the requested rate can be delivered.
准入控制应将请求速率与剩余可用带宽进行比较，以确定请求速率是否可以交付。
For Controlled Load Service, a flow can be admitted as long as there is sufficient bandwidth available (after the above computation) to meet the rate requirement, and if there is sufficient buffer space (sum of the token bucket sizes does not exceed the buffer capacity). While some statistical multiplexing could be done in computing admissibility, the nature of the low-bitrate links could make this approach risky as any delay incurred to address a temporary overcommitment could be difficult to amortize.
对于受控负载服务，只要有足够的可用带宽（在上述计算之后）来满足速率要求，并且如果有足够的缓冲空间（令牌桶大小的总和不超过缓冲容量），就可以接纳流。虽然在计算可容许性时可以进行一些统计复用，但低比特率链路的性质可能使这种方法具有风险，因为为解决临时超额承诺而产生的任何延迟都可能难以摊销。
Guaranteed Service requires the calculation of C and D error terms. C is a rate-dependent error term and there are no special considerations affecting its calculation in the low-speed link environment. The D term is calculated from the inherent link delay (Dlink) plus the potential worst case delay due to transmission of another fragment or suspend/resume overhead. Thus, D should be calculated as
保证服务要求计算C和D误差项。C是一个与速率相关的误差项，在低速链路环境中，没有影响其计算的特殊因素。D项是根据固有链路延迟（Dlink）加上由于传输另一个片段或暂停/恢复开销而产生的潜在最坏情况延迟来计算的。因此，D应计算为
D = Dlink + FRAG/LinkRate
D = Dlink + FRAG/LinkRate
in the case of a fragementing implementation and
在碎片化实施的情况下，以及
D = Dlink + pHeader + pDelay
D = Dlink + pHeader + pDelay
for a suspend/resume implementation.
用于挂起/恢复实现。
We may think of the link scheduler as having two parts, the first of which schedules packets for transmission before passing them to the second part of the scheduler -- the link level scheduler -- which is responsible for fragmenting packets, mapping them to classes, and scheduling among the classes.
我们可以认为链路调度器有两个部分，第一个部分在将数据包传递给调度器的第二部分（链路级调度器）之前调度数据包以进行传输，链路级调度器负责将数据包分段，将数据包映射到类，并在类之间进行调度。
In the dynamic class mapping mode of Section 3.3, when deciding which class to assign a packet to, the link level scheduler should take account of the sizes of other packets currently assigned to the same class. In particular, packets with the tightest delay constraints should not be assigned to classes for which relatively large packets are in the process of being transmitted.
在第3.3节的动态类映射模式中，当决定将数据包分配给哪个类时，链路级调度器应考虑当前分配给同一类的其他数据包的大小。特别是，具有最严格延迟约束的数据包不应分配给正在传输相对较大数据包的类。
In either the dynamic or the static class mapping approach, note that the link-level scheduler SHOULD control how much link bandwidth is assigned to each class at any instant. The scheduler should assign bandwidth to a class according to the bandwidth reserved for the sum of all flows which currently have packets assigned to the class. Note that in the example of Section 3.3, when packets from flows A and E were assigned to the same class (class 1), the scheduler assigned more bandwidth to class 1, reflecting the fact that it was carrying traffic from reservations totaling 20kbit/s while the other classes were carrying only 10kbit/s.
在动态或静态类映射方法中，请注意，链路级调度器应该控制在任何时刻分配给每个类的链路带宽。调度器应该根据为当前已将数据包分配给类的所有流的总和保留的带宽为类分配带宽。请注意，在第3.3节的示例中，当来自流A和E的数据包被分配到同一类（类1）时，调度器将更多带宽分配给类1，这反映了这样一个事实，即它正在承载总计20kbit/s的预留流量，而其他类仅承载10kbit/s。
General security considerations for MLPPP and PPP links are addressed in RFC 1990 [12] and RFC 1661 [13], respectively. Security considerations relevant to RSVP, used as the signaling protocol for integrated services, are discussed in RFC 2209 [14].
MLPPP和PPP链路的一般安全注意事项分别在RFC 1990[12]和RFC 1661[13]中阐述。RFC 2209[14]讨论了与用作综合业务信令协议的RSVP相关的安全注意事项。
A specific security consideration relevant to providing quality of service over PPP links appears when relying on either observed or theoretical average packet expansion during admission control due to bit- or byte-stuffing. Implementations based on these packet-expansion values contain a potential vulnerability to denial of service attacks. An adversary could intentionally send traffic that will result in worst case bit- or byte stuffing packet expansion. This in turn could result in quality of service guarantees not being met for other flows due to overly permissive admission control. This potential denial of service attack argues strongly for using a worst case expansion factor in admission control calculations, even for controlled load service.
由于位或字节填充，在接纳控制期间依赖观察到的或理论上的平均分组扩展时，出现了与通过PPP链路提供服务质量相关的特定安全考虑。基于这些数据包扩展值的实现包含拒绝服务攻击的潜在漏洞。对手可能故意发送流量，这将导致最坏情况下的位或字节填充数据包扩展。这反过来可能导致由于过度许可的准入控制，其他流无法满足服务质量保证。这种潜在的拒绝服务攻击强烈主张在准入控制计算中使用最坏情况扩展因子，即使是对于受控负载服务。
Beyond the considerations documented above, this document introduces no new security issues on top of those discussed in the companion ISSLL documents [1], [2] and [3] and AVT document [4]. Any use of these service mappings assumes that all requests for service are authenticated appropriately.
除了上面记录的注意事项外，本文件在ISSLL配套文件[1]、[2]和[3]以及AVT文件[4]中讨论的安全问题之外，没有引入任何新的安全问题。这些服务映射的任何使用都假定所有服务请求都经过适当的身份验证。
[1] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.
[1] Bormann，C.，“通过低比特率链路提供综合服务”，RFC 2689，1999年9月。
[2] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[2] Bormann，C.，“多链路PPP的多类扩展”，RFC 2686，1999年9月。
[3] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[3] Bormann，C.“实时定向HDLC样帧中的PPP”，RFC 2687，1999年9月。
[4] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[4] Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[5] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[5] Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[6] Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[6] 帕特里奇，C.和R.盖林，“保证服务质量规范”，RFC 2212，1997年9月。
[7] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[7] Shenker，S.和J.Wroclawski，“综合业务网络元件的一般特征参数”，RFC 2215，1997年9月。
[8] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links", RFC 1144, February 1990.
[8] Jacobson，V.，“低速串行链路的TCP/IP压缩”，RFC 1144，1990年2月。
[9] B. Davie et al. "Integrated Services in the Presence of Compressible Flows", Work in Progress (draft-davie-intserv-compress-00.txt), Feb. 1999.
[9] B.Davie等人，“存在可压缩流时的综合服务”，正在进行的工作（draft-Davie-intserv-compress-00.txt），1999年2月。
[10] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[10] Engan，M.，Casner，S.和C.Bormann，“PPP上的IP报头压缩”，RFC 2509，1999年2月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[11] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradettim, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[12] K.Sklower、Lloyd、B.McGregor、G.Carr、D.和T.Coradettim，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[13] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[13] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[14] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[14] Braden，R.和L.Zhang，“资源预留协议（RSVP）——第1版消息处理规则”，RFC 2209，1997年9月。
Steve Jackowski Deterministic Networks, Inc. 245M Mt Hermon Rd, #140 Scotts Valley, CA 95060 USA
Steve Jackowski Deterministic Networks，Inc.美国加利福尼亚州斯科茨谷140号埃蒙山路245M号，邮编95060
Phone: +1 (408) 813 6294
EMail: stevej@DeterministicNetworks.com
Phone: +1 (408) 813 6294
EMail: stevej@DeterministicNetworks.com
David Putzolu Intel Architecture Labs (IAL) JF3-206-H10 2111 NE 25th Avenue Hillsboro, OR 97124-5961 USA
David Putzolu英特尔体系结构实验室（IAL）JF3-206-H10 2111美国希尔斯堡东北25大道25号，邮编：97124-5961
Phone: +1 (503) 264 4510
EMail: David.Putzolu@intel.com
Phone: +1 (503) 264 4510
EMail: David.Putzolu@intel.com
Eric S. Crawley Argon Networks, Inc. 25 Porter Road Littleton, MA 01460 USA
美国马萨诸塞州利特尔顿波特路25号Eric S.Crawley Argon Networks，Inc.01460
Phone: +1 (978) 486-0665
EMail: esc@argon.com
Phone: +1 (978) 486-0665
EMail: esc@argon.com
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 USA
布鲁斯·戴维斯思科系统公司，美国马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
Phone: +1 (978) 244 8921
EMail: bdavie@cisco.com
Phone: +1 (978) 244 8921
EMail: bdavie@cisco.com
Acknowledgements
致谢
This document draws heavily on the work of the ISSLL WG of the IETF.
本文件大量借鉴了IETF ISSLL工作组的工作。
The protocols used in current implementations of POTS modems can exhibit significant changes in link rate and delay over the duration of a connection. Admission control and link scheduling algorithms used with these devices MUST be prepared to compensate for this variability in order to provide a robust implementation of integrated services.
在POTS调制解调器的当前实现中使用的协议可以在连接持续时间内表现出链路速率和延迟的显著变化。必须准备好与这些设备一起使用的准入控制和链路调度算法来补偿这种变化，以便提供集成服务的健壮实现。
Link rate on POTS modems is typically reported at connection time. This value may change over the duration of the connection. The v.34 protocol, used in most POTS modems, is adaptive to link conditions, and is able to recalibrate transmission rate multiple times over the duration of a connection. Typically this will result in a small (~10%) increase in transmission rate over the initial connection within the first minute of a call. It is important to note, however, that other results are possible as well, including decreases in available bandwidth. Admission control algorithms MUST take such changes into consideration as they occur, and implementations MUST be able to gracefully handle the pathological case where link rate actually drops below the currently reserved capacity of a link.
POTS调制解调器上的链路速率通常在连接时报告。此值可能会随着连接的持续时间而更改。在大多数POTS调制解调器中使用的v.34协议能够适应链路条件，并且能够在连接期间多次重新校准传输速率。通常，这将导致在呼叫的第一分钟内，初始连接的传输速率略微增加（~10%）。然而，需要注意的是，其他结果也是可能的，包括可用带宽的减少。接纳控制算法必须在发生这些变化时考虑这些变化，并且实现必须能够优雅地处理链路速率实际下降到链路当前保留容量以下的病态情况。
Delay experienced by traffic over POTS modems can vary significantly over time. Unlike link rate, the delay often does not converge to a stable value. The v.42 protocol is used in most POTS modems to provide link-layer reliability. This reliability, which is implemented via retransmission, can cause frames to experience significant delays. Retransmissions also implicitly steal link bandwidth from other traffic. These delays and reductions in link bandwidth make it extremely difficult to honor a guaranteed service reservation. On a link that is actually lightly or moderately loaded, a controlled load service can to some extent accept such events as part of the behavior of a lightly loaded link. Unfortunately, as actual link utilization increases, v.42 retransmissions have the potential of stealing larger and larger fractions of available link bandwidth; making even controlled load service difficult to offer at high link utilization when retransmissions occur.
POTS调制解调器上的通信所经历的延迟会随着时间的推移而显著变化。与链路速率不同，延迟通常不会收敛到稳定值。v.42协议用于大多数POTS调制解调器，以提供链路层可靠性。这种通过重传实现的可靠性可能导致帧经历重大延迟。重传还隐式地从其他流量中窃取链路带宽。这些延迟和链路带宽的减少使得履行有保证的服务预约非常困难。在实际轻微或适度加载的链接上，受控加载服务可以在某种程度上接受此类事件，作为轻微加载链接行为的一部分。不幸的是，随着实际链路利用率的增加，v.42重传有可能窃取越来越多的可用链路带宽；当发生重传时，在高链路利用率下难以提供均匀受控负载服务。
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。