Network Working Group Y. Bernet
Request for Comments: 2997 Microsoft
Category: Standards Track A. Smith
Allegro Networks
B. Davie
Cisco Systems
November 2000
Network Working Group Y. Bernet
Request for Comments: 2997 Microsoft
Category: Standards Track A. Smith
Allegro Networks
B. Davie
Cisco Systems
November 2000
Specification of the Null Service Type
空服务类型的规范
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
In the typical Resource Reservation Protocol (RSVP)/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, ERP applications are often mission critical and require some form of prioritized service, but cannot readily specify their resource requirements. To serve such applications, we introduce the notion of the 'Null Service'. The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling [intdiff]. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service.
在典型的资源预留协议（RSVP）/Intserv模型中，应用程序请求特定的Intserv服务类型，并量化该服务所需的资源。对于某些应用程序，服务参数的确定最好由网络管理员自行决定。例如，ERP应用程序通常是任务关键型的，需要某种形式的优先服务，但不能很容易地指定其资源需求。为了服务于此类应用程序，我们引入了“空服务”的概念。空服务允许应用程序使用RSVP信令向网络服务质量（QoS）策略代理标识自己。但是，它不要求它们具体说明所需资源。网络中的QoS策略代理通过应用适用于应用程序的QoS策略（由网络管理员确定）进行响应。这种RSVP使用模式特别适用于将区分服务（diffserv）QoS机制与RSVP信令[intdiff]相结合的网络。在此环境中，QoS策略代理可以将发信号的应用程序的通信量定向到特定的区分服务类别。
Using standard RSVP/Intserv signaling, applications running on hosts issue requests for network resources by communicating the following information to network devices:
使用标准RSVP/Intserv信令，主机上运行的应用程序通过向网络设备传送以下信息来发出网络资源请求：
1. A requested service level (Guaranteed or Controlled Load). 2. The quantity of resources required at that service level. 3. Classification information by which the network can recognize specific traffic (filterspec). 4. Policy/identity information indicating the user and/or the application for which resources are required.
1. 请求的服务级别（保证或控制负载）。2.该服务级别所需的资源量。3.网络可以识别特定流量的分类信息（filterspec）。4.指示需要资源的用户和/或应用程序的策略/标识信息。
In response, standard RSVP aware network nodes choose to admit or deny a resource request. The decision is based on the availability of resources along the relevant path and on policies. Policies define the resources that may be granted to specific users and/or applications. When a resource request is admitted, network nodes install classifiers that are used to recognize the admitted traffic and policers that are used to assure that the traffic remains within the limits of the resources requested.
作为响应，标准RSVP感知网络节点选择接纳或拒绝资源请求。该决定基于相关路径上的资源可用性和政策。策略定义可授予特定用户和/或应用程序的资源。当资源请求被接纳时，网络节点安装用于识别接纳的流量的分类器和用于确保流量保持在请求的资源限制内的策略。
The Guaranteed and Controlled Load Intserv services are not suitable for certain applications that are unable to (or choose not to)specify the resources they require from the network. Diffserv services are better suited for this type of application. Nodes in a diffserv network are typically provisioned to classify arriving packets to some small number of behavior aggregates (BAs) [diffarch]. Traffic is handled on a per-BA basis. This provisioning tends to be 'top-down' with respect to end-user traffic flows in the sense that there is no signaling between hosts and the network. Instead, the network administrator uses a combination of heuristics, measurement and experience to provision the network devices to handle aggregated traffic, with no deterministic knowledge of the volume of traffic that will arrive at any specific node.
保证和控制负载Intserv服务不适用于某些无法（或选择不）指定其从网络中所需资源的应用程序。Diffserv服务更适合这种类型的应用程序。diffserv网络中的节点通常被配置为将到达的数据包分类到一些少量的行为聚合（BAs）[diffarch]。交通量按英国航空公司（BA）处理。在主机和网络之间没有信令的意义上，这种供应倾向于针对最终用户流量“自上而下”。相反，网络管理员使用启发式、测量和经验的组合来提供网络设备以处理聚合的通信量，而不确定将到达任何特定节点的通信量。
In applying diffserv mechanisms to manage application traffic, network administrators are faced with two challenges:
在应用diffserv机制管理应用程序流量时，网络管理员面临两个挑战：
1. Provisioning - network administrators need to anticipate the volume of traffic likely to arrive at each network node for each diffserv BA. If the volume of traffic arriving is likely to exceed the capacity available for the BA claimed, the network administrator has the choice of increasing the capacity for the BA, reducing the volume of traffic claiming the BA, or compromising service to all traffic arriving for the BA.
1. 资源调配-网络管理员需要预测每个diffserv BA可能到达每个网络节点的流量。如果到达的流量很可能超过所申请BA的可用容量，则网络管理员可以选择增加BA的容量，减少申请BA的流量，或者牺牲对所有到达BA的流量的服务。
2. Classification - diffserv nodes classify traffic to user and/or application, based on the diff-serv codepoint (DSCP) in each packet's IP header or based on other fields in the packet's IP header (source/destination address/port and protocol). The latter method of classification is referred to as MF classification. This method of classification may be unreliable and imposes a management burden.
2. 分类-区分服务节点根据每个数据包IP报头中的区分服务代码点（DSCP）或数据包IP报头中的其他字段（源/目标地址/端口和协议），对用户和/或应用程序的流量进行分类。后一种分类方法称为MF分类。这种分类方法可能不可靠，并造成管理负担。
By using RSVP signaling, the management of application traffic in diffserv networks can be significantly facilitated. (Note that RSVP/diffserv interoperability has been discussed previously in the context of the Guaranteed and Controlled Load Intserv services.) This document focuses on RSVP/diffserv interoperability in the context of the Null Service.
通过使用RSVP信令，diffserv网络中的应用流量管理可以大大简化。（请注意，RSVP/diffserv互操作性之前已在保证和控制负载Intserv服务的上下文中讨论过。）本文档重点介绍空服务上下文中的RSVP/diffserv互操作性。
In the proposed mechanism, the RSVP sender offers the new service type, 'Null Service Type' in the ADSPEC that is included with the PATH message. A new Tspec corresponding to the new service type is added to the SENDER_TSPEC. In addition, the RSVP sender will typically include with the PATH message policy objects identifying the user, application and sub application ID [identity, application].
在建议的机制中，RSVP发送方在路径消息中包含的ADSPEC中提供了新的服务类型“Null service type”。将与新服务类型对应的新Tspec添加到发送方\u Tspec。此外，RSVP发送方通常会在路径消息策略对象中包含标识用户、应用程序和子应用程序ID[标识、应用程序]的对象。
(Note that at this time, the new Tspec is defined only to carry the maximum packet size parameter (M), for the purpose of avoiding fragmentation. No other parameters are defined.)
（请注意，此时，新的Tspec仅定义为携带最大数据包大小参数（M），以避免碎片。未定义其他参数。）
Network nodes receiving these PATH messages interpret the service type to indicate that the application is requesting no specific service type or quantifiable resources. Instead, network nodes manage the traffic flow based on the requesting user, the requesting application and the type of application sub-flow.
接收这些路径消息的网络节点解释服务类型，以指示应用程序没有请求特定的服务类型或可量化的资源。相反，网络节点基于请求用户、请求应用程序和应用程序子流的类型来管理业务流。
This mechanism offers significant advantages over a pure diffserv network. At the very least, it informs each network node which would be affected by the traffic flow (and which is interested in intercepting the signaling) of:
与纯区分服务网络相比，这种机制具有显著的优势。至少，它会通知每个将受业务流影响（并且有兴趣拦截信令）的网络节点：
1. The demand for resources in terms of number of flows of a particular type traversing the node. 2. The binding between classification information and user, application and sub-application.
1. 以穿过节点的特定类型的流的数量表示的资源需求。2.分类信息与用户、应用程序和子应用程序之间的绑定。
This information is particularly useful to policy enforcement points and policy decision points (PEPs and PDPs). The network administrator can configure these elements of the policy management system to apply appropriate policy based on the identity of the user, the application and the specific sub application ID.
这些信息对于政策执行点和政策决策点（政治公众人物和政策制定点）特别有用。网络管理员可以配置策略管理系统的这些元素，以根据用户、应用程序和特定子应用程序ID的身份应用适当的策略。
PEPs and PDPs may be configured to return an RSVP RESV message to the sender. The returned RESV message may include a DCLASS object [dclass]. The DCLASS object instructs the sender to mark packets on the corresponding flow with a specific DSCP (or set of DSCPs). This mechanism allows PEP/PDPs to affect the volume of traffic arriving at a node for any given BA. It enables the PEP/PDP to do so based on sophisticated policies.
PEP和PDP可配置为向发送方返回RSVP RESV消息。返回的RESV消息可能包括DCLASS对象[DCLASS]。DCLASS对象指示发送方使用特定的DSCP（或一组DSCP）在相应流上标记数据包。该机制允许PEP/PDP影响任何给定BA到达节点的流量。它使政治公众人物/人民民主党能够基于复杂的政策来实现这一目标。
In any network in which per-flow signaling is used, it is wise to consider scalability concerns. The Null Service encourages signaling for a broader set of applications than that which would otherwise be signaled for. However, RSVP signaling does not, in general, generate a significant amount of traffic relative to the actual data traffic associated with the session. In addition, the Null Service does not encourage every application to signal. It should be used by applications that are considered mission critical or needing QoS management by network administrators.
在使用每个流信令的任何网络中，考虑可伸缩性问题是明智的。空服务鼓励为更广泛的应用程序集发送信号，而不是为其他应用程序发送信号。然而，RSVP信令通常不会产生相对于与会话相关联的实际数据通信量的大量通信量。此外，空服务并不鼓励每个应用程序发出信号。它应该被网络管理员认为是关键任务或需要QoS管理的应用程序使用。
Perhaps of more concern is the impact on processing resources at network nodes that process the signaling messages. When considering this issue, it's important to point out that it is not necessary to process the signaling messages at each network node. In fact, the combination of RSVP signaling with diff-serv networks may afford significant benefits even when the RSVP messages are processed only at certain key nodes (such as boundaries between network domains, first-hop routers, PEPs or any subset of these). Individual nodes should be enabled or disabled for RSVP processing at the discretion of the network administrator. See [intdiff] for a discussion of the impact of RSVP signaling on diff-serv networks.
也许更值得关注的是对处理信令消息的网络节点上的处理资源的影响。在考虑这个问题时，必须指出，不需要在每个网络节点上处理信令消息。事实上，即使仅在某些关键节点（例如网络域、第一跳路由器、pep或其任何子集之间的边界）处处理RSVP消息，RSVP信令与diff-serv网络的组合也可以提供显著的好处。应根据网络管理员的决定启用或禁用单个节点进行RSVP处理。有关RSVP信令对区分服务网络的影响的讨论，请参见[intdiff]。
In any case, per-flow state is not necessarily required, even in nodes that apply per-flow processing.
在任何情况下，不一定需要每个流状态，即使在应用每个流处理的节点中也是如此。
Network nodes that adhere to the RSVP spec should transparently pass signaling messages for the Null Service. As such, it is possible to introduce a small number of PEPs that are enabled for Null Service into a legacy network and to realize the benefits described in this document.
遵守RSVP规范的网络节点应透明地传递空服务的信令消息。因此，有可能在传统网络中引入少量支持空服务的PEP，并实现本文档中描述的好处。
This document does not preclude applications from offering both a quantitative Intserv service (Guaranteed or Controlled Load)and the Null Service, at the same time. An example of such an application would be a telephony application that benefits from the Guaranteed Service but is able to adapt to a less strict service. By advertising its support for both, the application enables network policy to decide which service type to provide.
本文档不排除应用程序同时提供定量Intserv服务（保证或控制负载）和空服务。此类应用程序的一个示例是电话应用程序，该应用程序受益于保证服务，但能够适应较不严格的服务。通过宣传其对两者的支持，应用程序使网络策略能够决定提供哪种服务类型。
The RSVP sender constructs an initial RSVP ADSPEC object specifying the Null Service Type. Since there are no service specific parameters associated with this service type, the associated ADSPEC fragment is empty and contains only the header word. Network nodes may or may not supply valid values for bandwidth and latency general parameters. As such, they may use the unknown values defined in [RFC2216].
RSVP发送方构造一个初始RSVP ADSPEC对象，指定空服务类型。由于没有与此服务类型关联的特定于服务的参数，因此关联的ADSPEC片段是空的，并且只包含头字。网络节点可能会也可能不会为带宽和延迟常规参数提供有效值。因此，他们可以使用[RFC2216]中定义的未知值。
The ADSPEC is added to the RSVP PATH message created at the sender.
ADSPEC被添加到在发送方创建的RSVP PATH消息中。
An additional Tspec is defined to correspond to the Null Service. If only the Null Service is offered in the ADSPEC, then this is the only Tspec included in the SENDER_TSPEC object. If guaranteed or controlled load services are also offered in the ADSPEC, then the new Tspec is appended following the standard Intserv token-bucket Tspec [RFC2210].
另外定义了一个Tspec以对应于空服务。如果ADSPEC中仅提供空服务，则这是SENDER_Tspec对象中包含的唯一Tspec。如果ADSPEC中还提供有保证或受控的负载服务，则新的Tspec将附加在标准Intserv令牌桶Tspec[RFC2210]之后。
Receivers may respond to PATH messages by generating an RSVP RESV message including a FLOWSPEC object. The FLOWSPEC object should specify that it is requesting the Null Service. It is possible that, in the future, a specific Rspec may be defined to correspond to the new service type.
接收器可通过生成包括FLOWSPEC对象的RSVP RESV消息来响应路径消息。FLOWSPEC对象应该指定它正在请求空服务。将来可能定义特定Rspec以对应于新服务类型。
A standard RSVP ADSPEC object is described in [RFC2210]. It includes a message header and a default general parameters fragment. Following the default general parameters fragment are fragments for each supported service type.
[RFC2210]中描述了标准RSVP ADSPEC对象。它包括一个消息头和一个默认的通用参数片段。默认的常规参数片段后面是每个支持的服务类型的片段。
The Null Service ADSPEC includes the message header and the default general parameters fragment, followed by a single fragment denoting the Null Service. The new fragment introduced for the Null Service is formatted as follows:
空服务ADSPEC包括消息头和默认的通用参数片段，后面是表示空服务的单个片段。为空服务引入的新片段的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 (a) |x| Reserved | 0 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 (a) |x| Reserved | 0 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a - indicates Null Service (6). x - is the break-bit. b - indicates zero words in addition to the header.
a-表示空服务（6）。x-是断裂位。b-除标题外，表示零个字。
A complete ADSPEC supporting only the Null Service is illustrated below:
仅支持空服务的完整ADSPEC如下所示：
31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Reserved | Msg length -1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| Reserved | 8 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (e) | (f) | 1 (g) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | IS hop cnt (32-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (h) | (i) | 1 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (k) | (l) | 1 (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (n) | (o) | 1 (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Composed MTU (32-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 6 (q) |x| Reserved | 0 (r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Reserved | Msg length -1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| Reserved | 8 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (e) | (f) | 1 (g) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | IS hop cnt (32-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (h) | (i) | 1 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (k) | (l) | 1 (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (n) | (o) | 1 (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Composed MTU (32-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 6 (q) |x| Reserved | 0 (r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Message Header:
(a) - Message header and version number
(b) - Message length (10 words not including header)
Word 1: Message Header:
(a) - Message header and version number
(b) - Message length (10 words not including header)
Words 2-10: Default general characterization parameters
(c) - Per-Service header, service number 1 (Default General
Parameters)
(x) - Global Break bit (NON_IS_HOP general parameter 2)
(d) - Length of General Parameters data block (8 words)
(e) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS general
parameter)
(f) - Parameter 4 flag byte
(g) - Parameter 4 length, 1 word not including header
(h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general
parameter)
(i) - Parameter 6 flag byte
(j) - Parameter 6 length, 1 word not including header
(k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general
parameter)
(l) - Parameter 8 flag byte
Words 2-10: Default general characterization parameters
(c) - Per-Service header, service number 1 (Default General
Parameters)
(x) - Global Break bit (NON_IS_HOP general parameter 2)
(d) - Length of General Parameters data block (8 words)
(e) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS general
parameter)
(f) - Parameter 4 flag byte
(g) - Parameter 4 length, 1 word not including header
(h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general
parameter)
(i) - Parameter 6 flag byte
(j) - Parameter 6 length, 1 word not including header
(k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general
parameter)
(l) - Parameter 8 flag byte
(m) - Parameter 8 length, 1 word not including header
(n) - Parameter ID, parameter 10 (PATH_MTU general parameter)
(o) - Parameter 10 flag byte
(p) - Parameter 10 length, 1 word not including header
(m) - Parameter 8 length, 1 word not including header
(n) - Parameter ID, parameter 10 (PATH_MTU general parameter)
(o) - Parameter 10 flag byte
(p) - Parameter 10 length, 1 word not including header
Word 11: Null Service parameters
字11：空服务参数
(q) - Per-Service header, service number 6 (Null) (x) - Break bit for Null Service (r) - Length (0) of per-service data not including header word.
(q) -每个服务头，服务编号6（空）（x）-空服务的中断位（r）-每个服务数据的长度（0），不包括头字。
Note that the standard rules for parsing ADSPEC service fragments ensure that the ADSPEC will not be rejected by legacy network elements. Specifically, these rules state that a network element encountering a per-service data header which it does not understand should set bit 23 (the break-bit) to indicate that the service is not supported and should use the length field from the header to skip over the rest of the fragment.
请注意，解析ADSPEC服务片段的标准规则确保ADSPEC不会被遗留网络元素拒绝。具体而言，这些规则规定，遇到不理解的每服务数据头的网元应设置位23（中断位），以指示不支持该服务，并应使用头中的长度字段跳过片段的其余部分。
Also note that it is likely that it will not be possible for hosts or network nodes to generate meaningful values for words 5 and/or 7 (bandwidth estimates and path latency), due to the nature of the service. In this case, the unknown values from [RFC2216] should be used.
还请注意，由于服务的性质，主机或网络节点可能无法为字5和/或7生成有意义的值（带宽估计和路径延迟）。在这种情况下，应使用[RFC2216]中的未知值。
The following Tspec is defined to correspond to the Null Service:
定义以下Tspec以对应于空服务：
31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 6 (a) |0| Reserved | 2 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 128 (c) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 6 (a) |0| Reserved | 2 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 128 (c) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Service header (a) - Service number 6 (Null Service) (b) - Length of per-service data, 2 words not including per-service header
单词1：服务头（a）-服务编号6（空服务）（b）-每个服务数据的长度，每个服务头不包括2个单词
Word 2-3: Parameter
(c) - Parameter ID, parameter 128 (Null Service TSpec)
(d) - Parameter 128 flags (none set)
(e) - Parameter 128 length, 1 words not including parameter header
Word 2-3: Parameter
(c) - Parameter ID, parameter 128 (Null Service TSpec)
(d) - Parameter 128 flags (none set)
(e) - Parameter 128 length, 1 words not including parameter header
Note that the illustration above does not include the standard RSVP SENDER_TSPEC object header, nor does it include the sub-object header (which indicates the message format version number and length), defined in RFC 2205 and RFC 2210, respectively.
注意，上图不包括标准RSVP SENDER_TSPEC对象头，也不包括RFC 2205和RFC 2210中分别定义的子对象头（指示消息格式版本号和长度）。
In the case that only the Null Service is advertised in the ADSPEC, the Tspec above would be appended immediately after the SENDER_TSPEC object header and sub-object header. In the case that additional service types are advertised, requiring the token bucket specific Tspec defined in RFC2210, the Tspec above would be appended following the token bucket Tspec, which would in turn follow the object header and sub-object header.
在ADSPEC中仅播发空服务的情况下，上面的Tspec将紧跟在发送方\u Tspec对象头和子对象头之后。在需要RFC2210中定义的特定于令牌桶的Tspec的额外服务类型被通告的情况下，上述Tspec将被附加在令牌桶Tspec之后，令牌桶Tspec将依次跟随对象头和子对象头。
The format of an RSVP FLOWSPEC object originating at a receiver requesting the Null Service is shown below. The value of 6 in the per-service header (field (c), below) indicates that Null Service is being requested.
在请求空服务的接收者处发起的RSVP FLOWSPEC对象的格式如下所示。每个服务头（下面的字段（c））中的值6表示请求的是空服务。
31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 3 (b) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 6 (c) |0| Reserved | 2 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 128 (e) | 0 (f) | 1 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 3 (b) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 6 (c) |0| Reserved | 2 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 128 (e) | 0 (f) | 1 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (3 words not including header)
(c) - Service header, service number 6 (Null)
(d) - Length of data, 2 words not including per-service header
(e) - Parameter ID, parameter 128 (Null Service TSpec)
(f) - Parameter 128 flags (none set)
(g) - Parameter 128 length, 1 words not including parameter header
(a) - Message format version number (0)
(b) - Overall length (3 words not including header)
(c) - Service header, service number 6 (Null)
(d) - Length of data, 2 words not including per-service header
(e) - Parameter ID, parameter 128 (Null Service TSpec)
(f) - Parameter 128 flags (none set)
(g) - Parameter 128 length, 1 words not including parameter header
DCLASS objects may be included in RESV messages. For details regarding the DCLASS object format, see [dclass].
RESV消息中可能包含DCLASS对象。有关DCLASS对象格式的详细信息，请参阅[DCLASS]。
The message formatting and usage rules described in this note raise no new security issues beyond standard RSVP.
本说明中描述的消息格式和使用规则不会引发标准RSVP之外的新安全问题。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）-第1版功能规范”，RFC 22052997年9月。
[RFC2216] Shenker, S. and J. Wroclawski, "Network Element QoS Control Service Specification Template", RFC 2216, September 1997.
[RFC2216]Shenker，S.和J.Wroclawski，“网元QoS控制服务规范模板”，RFC 22161997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[intdiff] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Nichols, K., Speer, M., Braden, B. and B. Davie, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[intdiff]Bernet，Y.，Yavatkar，R.，Ford，P.，Baker，F.，Zhang，L.，Nichols，K.，Speer，M.，Braden，B.和B.Davie，“区分服务网络上的综合服务运营框架”，RFC 29982000年11月。
[diffarch] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[diffarch]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., "Identity Representation for RSVP", RFC 2752, January 2000.
[identity]Yadav，S.，Yavatkar，R.，Pabbati，R.，Ford，P.，Moore，T.，Herzog，S.，“RSVP的身份表示”，RFC 2752，2000年1月。
[application] Bernet, Y., "Application and Sub Application Identity Policy Objects for Use with RSVP", RFC 2872, June 2000.
[应用]Bernet，Y.，“与RSVP一起使用的应用程序和子应用程序标识策略对象”，RFC 28722000年6月。
[dclass] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[dclass]Bernet，Y.，“RSVP dclass对象的格式”，RFC 2996，2000年11月。
We thank Fred Baker, Dinesh Dutt, Nitsan Elfassy, John Schnizlein, Ramesh Pabbati and Sanjay Kaniyar for their comments on this memo.
我们感谢Fred Baker、Dinesh Dutt、Nitsan Elfasse、John Schnizlein、Ramesh Pabbati和Sanjay Kaniyar对本备忘录的评论。
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
Yoram Bernet微软一路微软雷德蒙，华盛顿州98052
Phone: +1 (425) 936-9568
EMail: Yoramb@microsoft.com
Phone: +1 (425) 936-9568
EMail: Yoramb@microsoft.com
Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119, USA
Andrew Smith Allegro Networks美国加利福尼亚州圣何塞圣伊格纳西奥大道6399号，邮编95119
FAX: +1 415 345 1827
Email: andrew@allegronetworks.com
FAX: +1 415 345 1827
Email: andrew@allegronetworks.com
Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford, MA 01824
布鲁斯·戴维斯思科系统公司马萨诸塞州切姆斯福德阿波罗大道250号01824
Phone: +1 (978)-244-8000
EMail: bsd@cisco.com
Phone: +1 (978)-244-8000
EMail: bsd@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。