Network Working Group A. Terzis
Request for Comments: 2745 UCLA
Category: Standards Track B. Braden
ISI
S. Vincent
Cisco Systems
L. Zhang
UCLA
January 2000
Network Working Group A. Terzis
Request for Comments: 2745 UCLA
Category: Standards Track B. Braden
ISI
S. Vincent
Cisco Systems
L. Zhang
UCLA
January 2000
RSVP Diagnostic Messages
RSVP诊断消息
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
摘要
This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. This specification describes the functionality, diagnostic message formats, and processing rules.
本文档指定了RSVP诊断工具，允许用户沿路径收集有关RSVP状态的信息。本规范描述了功能、诊断消息格式和处理规则。
In the basic RSVP protocol [RSVP], error messages are the only means for an end host to receive feedback regarding a failure in setting up either path state or reservation state. An error message carries back only the information from the failed point, without any information about the state at other hops before or after the failure. In the absence of failures, a host receives no feedback regarding the details of a reservation that has been put in place, such as whether, or where, or how, its own reservation request is being merged with that of others. Such missing information can be highly desirable for debugging purposes, or for network resource management in general.
在基本RSVP协议[RSVP]中，错误消息是终端主机接收有关设置路径状态或保留状态失败的反馈的唯一方式。错误消息仅从失败点返回信息，而不包含关于失败之前或之后其他跃点状态的任何信息。在没有故障的情况下，主机不会收到有关已落实预订的详细信息的反馈，例如是否、在何处或如何将其自己的预订请求与其他人的预订请求合并。这种丢失的信息对于调试目的或一般的网络资源管理非常有用。
This document specifies the RSVP diagnostic facility, which is designed to fill this information gap. The diagnostic facility can be used to collect and report RSVP state information along the path from a receiver to a specific sender. It uses Diagnostic messages that are independent of other RSVP control messages and produce no side-effects; that is, they do not change any RSVP state at either nodes or hosts. Similarly, they provide not an error report but rather a collection of requested RSVP state information.
本文件规定了RSVP诊断设施，旨在填补这一信息空白。诊断设备可用于收集和报告从接收器到特定发送器的路径上的RSVP状态信息。它使用独立于其他RSVP控制消息且不产生副作用的诊断消息；也就是说，它们不会更改节点或主机上的任何RSVP状态。类似地，它们提供的不是错误报告，而是请求的RSVP状态信息的集合。
The RSVP diagnostic facility was designed with the following goals:
RSVP诊断设备的设计目标如下：
- To collect RSVP state information from every RSVP-capable hop along a path defined by path state, either for an existing reservation or before a reservation request is made. More specifically, we want to be able to collect information about flowspecs, refresh timer values, and reservation merging at each hop along the path.
- 从每个支持RSVP的跃点沿路径状态定义的路径收集RSVP状态信息，无论是针对现有保留还是在发出保留请求之前。更具体地说，我们希望能够收集有关流程规格、刷新计时器值和沿路径的每个跃点的保留合并的信息。
- To collect the IP hop count across each non-RSVP cloud.
- 收集每个非RSVP云的IP跃点计数。
- To avoid diagnostic packet implosion or explosion.
- 避免诊断数据包内爆或爆炸。
The following is specifically identified as a non-goal:
以下具体确定为非目标：
- Checking the resource availability along a path. Such functionality may be useful for future reservation requests, but it would require modifications to existing admission control modules that is beyond the scope of RSVP.
- 沿路径检查资源可用性。此类功能可能对未来的预订请求有用，但需要对RSVP范围之外的现有准入控制模块进行修改。
The diagnostic facility introduces two new RSVP message types: Diagnostic Request (DREQ) and Diagnostic Reply (DREP). A DREQ message can be originated by a client in a "requester" host, which may or may not be a participant of the RSVP session to be diagnosed. A client in the requester host invokes the RSVP diagnostic facility by generating a DREQ packet and sending it towards the LAST-HOP node, which should be on the RSVP path to be diagnosed. This DREQ packet specifies the RSVP session and a sender host for that session. Starting from the LAST-HOP, the DREQ packet collects information hop-by-hop as it is forwarded towards the sender (see Figure 1), until it reaches the ending node. Specifically, each RSVP-capable hop adds to the DREQ message a response (DIAG_RESPONSE) object containing local RSVP state for the specified RSVP session.
诊断工具引入了两种新的RSVP消息类型：诊断请求（DREQ）和诊断回复（DREP）。DREQ消息可以由“请求者”主机中的客户端发起，该主机可能是也可能不是要诊断的RSVP会话的参与者。请求者主机中的客户机通过生成DREQ数据包并将其发送到最后一跳节点来调用RSVP诊断工具，最后一跳节点应位于要诊断的RSVP路径上。此DREQ数据包指定RSVP会话和该会话的发送方主机。从最后一跳开始，DREQ数据包在向发送方转发时逐跳收集信息（见图1），直到到达结束节点。具体而言，每个支持RSVP的跃点向DREQ消息添加一个响应（DIAG_response）对象，该对象包含指定RSVP会话的本地RSVP状态。
When the DREQ packet reaches the ending node, the message type is changed to Diagnostic Reply (DREP) and the completed response is sent to the original requester node. Partial responses may also be returned before the DREQ packet reaches the ending node if an error condition along the path, such as "no path state", prevents further forwarding of the DREQ packet. To avoid packet implosion or explosion, all diagnostic packets are forwarded via unicast only.
当DREQ数据包到达结束节点时，消息类型更改为诊断应答（DREP），并将完成的响应发送到原始请求者节点。如果沿着路径的错误条件（例如“无路径状态”）阻止DREQ分组的进一步转发，则也可以在DREQ分组到达结束节点之前返回部分响应。为避免数据包内爆或爆炸，所有诊断数据包仅通过单播转发。
Thus, there are generally three nodes (hosts and/or routers) involved in performing the diagnostic function: the requester node, the starting node, and the ending node, as shown in Figure 1. It is possible that the client invoking the diagnosis function may reside directly on the starting node, in which case that the first two nodes are the same. The starting node is named "LAST-HOP", meaning the last-hop of the path segment to be diagnosed. The LAST-HOP node can be either a receiver node or an intermediate node along the path. The ending node is usually the specified sender host. However, the client can limit the length of the path segment to be diagnosed by specifying a hop-count limit in the DREQ message.
因此，通常有三个节点（主机和/或路由器）参与执行诊断功能：请求者节点、开始节点和结束节点，如图1所示。调用诊断功能的客户端可能直接驻留在起始节点上，在这种情况下，前两个节点是相同的。起始节点名为“LAST-HOP”，表示要诊断的路径段的最后一跳。最后一跳节点可以是沿路径的接收器节点或中间节点。结束节点通常是指定的发送方主机。但是，客户端可以通过在DREQ消息中指定跳数限制来限制要诊断的路径段的长度。
LAST-HOP Ending
Receiver node node Sender
__ __ __ __ __
| |---------| |------>| |--> ...-->| |--> ...---->| |
|__| |__| DREQ |__| DREQ |__| DREQ |__|
^ . |
| . |
| DREQ . DREP | DREP
| . |
_|_ DREP V V
Requester | | <------------------------------------
(client) |___|
LAST-HOP Ending
Receiver node node Sender
__ __ __ __ __
| |---------| |------>| |--> ...-->| |--> ...---->| |
|__| |__| DREQ |__| DREQ |__| DREQ |__|
^ . |
| . |
| DREQ . DREP | DREP
| . |
_|_ DREP V V
Requester | | <------------------------------------
(client) |___|
Figure 1
图1
DREP packets can be unicast from the ending node back to the requester either directly or hop-by-hop along the reverse of the path taken by the DREQ message to the LAST-HOP, and thence to the requester. The direct return is faster and more efficient, but the hop-by-hop reverse-path route may be the only choice if the packets have to cross firewalls. Hop-by-hop return is accomplished using an optional ROUTE object, which is built incrementally to contain a list of node addresses that the DREQ packet has passed through. The ROUTE object is then used in reverse as a source route to forward the DREP hop-by-hop back to the LAST-HOP node.
DREP数据包可以从结束节点单播回请求方，或者直接或沿着DREQ消息到最后一跳的反向路径逐跳返回，然后再返回请求方。直接返回更快、更有效，但如果数据包必须穿越防火墙，逐跳反向路径路由可能是唯一的选择。逐跳返回使用可选路由对象完成，该对象以增量方式构建，以包含DREQ数据包已通过的节点地址列表。然后，将ROUTE对象反向用作源路由，将DREP逐跳转发回最后一跳节点。
A DREQ message always consists of a single unfragmented IP datagram. On the other hand, one DREQ message can generate multiple DREP packets, each containing a fragment of the total DREQ message. When the path consists of many hops, the total length of a DREP message will exceed the MTU size before reaching the ending node; thus, the message has to be fragmented. Relying on IP fragmentation and reassembly, however, can be problematic, especially when DREP messages are returned to the requester hop-by-hop, in which case fragmentation/reassembly would have to be performed at every hop. To avoid such excessive overhead, we let the requester define a default path MTU size that is carried in every DREQ packet. If an intermediate node finds that the default MTU size is bigger than the MTU of the incoming interface, it reduces the default MTU size to the MTU size of the incoming interface. If an intermediate node detects that a DREQ packet size is larger than the default MTU size, it returns to the requester (in either manner described above) a DREP fragment containing accumulated responses. It then removes these responses from the DREQ and continues to forward it. The requester node can reassemble the resulting DREP fragments into a complete DREP message.
DREQ消息始终由单个未分段的IP数据报组成。另一方面，一个DREQ消息可以生成多个DREP数据包，每个数据包包含整个DREQ消息的一个片段。当路径由多个跳组成时，DREP消息的总长度在到达结束节点之前将超过MTU大小；因此，信息必须是碎片化的。然而，依赖IP碎片和重组可能会有问题，特别是当DREP消息逐跳返回给请求者时，在这种情况下，必须在每一跳执行碎片/重组。为了避免这种过度的开销，我们让请求者定义每个DREQ数据包中携带的默认路径MTU大小。如果中间节点发现默认MTU大小大于传入接口的MTU，则会将默认MTU大小减小为传入接口的MTU大小。如果中间节点检测到DREQ数据包大小大于默认MTU大小，它将向请求者（以上述任一方式）返回包含累积响应的DREP片段。然后从DREQ中删除这些响应并继续转发。请求者节点可以将生成的DREP片段重新组装成完整的DREP消息。
When discussing diagnostic packet handling, this document uses direction terminology that is consistent with the RSVP functional specification [RSVP], relative to the direction of data packet flow. Thus, a DREQ packet enters a node through an "outgoing interface" and is forwarded towards the sender through an "incoming interface", because DREQ packets travel in the reverse direction to the data flow.
在讨论诊断数据包处理时，本文档使用了与RSVP功能规范[RSVP]一致的方向术语，与数据包流的方向有关。因此，DREQ分组通过“传出接口”进入节点，并通过“传入接口”转发给发送方，因为DREQ分组以与数据流相反的方向移动。
Notice that DREQ packets can be forwarded only after the RSVP path state has been set up. If no path state exists, one may resort to the traceroute or mtrace facility to examine whether the unicast/multicast routing is working correctly.
请注意，只有在设置RSVP路径状态后，才能转发DREQ数据包。如果不存在路径状态，则可以使用traceroute或mtrace工具检查单播/多播路由是否正常工作。
Like other RSVP messages, DREQ and DREP messages consist of an RSVP Common Header followed by a variable set of typed RSVP data objects. The following sequence must be used:
与其他RSVP消息一样，DREQ和DREP消息由RSVP公共头和一组类型化RSVP数据对象组成。必须使用以下顺序：
+-----------------------------------+
| RSVP Common Header |
+-----------------------------------+
| Session object |
+-----------------------------------+
| Next-Hop RSVP_HOP object |
+-----------------------------------+
| DIAGNOSTIC object |
+-----------------------------------+
| (optional) DIAG_SELECT object |
+-----------------------------------+
| (optional) ROUTE object |
+-----------------------------------+
| zero or more DIAG_RESPONSE objects|
+-----------------------------------+
+-----------------------------------+
| RSVP Common Header |
+-----------------------------------+
| Session object |
+-----------------------------------+
| Next-Hop RSVP_HOP object |
+-----------------------------------+
| DIAGNOSTIC object |
+-----------------------------------+
| (optional) DIAG_SELECT object |
+-----------------------------------+
| (optional) ROUTE object |
+-----------------------------------+
| zero or more DIAG_RESPONSE objects|
+-----------------------------------+
The session object identifies the RSVP session for which the state information is being collected. We describe each of the other parts.
会话对象标识正在为其收集状态信息的RSVP会话。我们描述了其他每个部分。
The RSVP message common header is defined in [RSVP]. The following specific exceptions and extensions are needed for DREP and DREQ.
RSVP消息公共头在[RSVP]中定义。DREP和DREQ需要以下特定的异常和扩展。
Type field: define:
类型字段：定义：
Type = 8: DREQ Diagnostic Request
类型=8:DREQ诊断请求
Type = 9: DREP Diagnostic Reply
类型=9:DREP诊断应答
RSVP length:
RSVP长度：
If this is a DREP message and the MF flag in the DIAGNOSTIC object (see below) is set, this field indicates the length of this single DREP fragment rather than the total length of the complete DREP reply message (which cannot generally be known in advance).
如果这是一条DREP消息，并且在诊断对象（见下文）中设置了MF标志，则此字段指示此单个DREP片段的长度，而不是完整DREP回复消息的总长度（通常无法提前知道）。
This RSVP_HOP object carries the LIH of the interface through which the DREQ should be received at the upstream node. This object is updated hop-by hop. It is used for the same reasons that a RESV message contains an RSVP_HOP object: to distinguish logical interfaces and avoid problems caused by routing asymmetries and non-RSVP clouds.
这个RSVP_-HOP对象携带接口的LIH，通过该LIH，DREQ应该在上游节点接收。此对象逐跳更新。使用它的原因与RESV消息包含RSVP_-HOP对象的原因相同：用于区分逻辑接口并避免路由不对称和非RSVP云引起的问题。
While the IP address is not really used during DREQ processing, for consistency with the use of the RSVP_HOP object in other RSVP messages, the IP address in the RSVP_HOP object to contain the address of the interface through which the DREQ was sent.
虽然在DREQ处理期间并未真正使用IP地址，但为了与其他RSVP消息中使用RSVP_-HOP对象的一致性，RSVP_-HOP对象中的IP地址应包含发送DREQ的接口的地址。
A DIAGNOSTIC object contains the common diagnostic control information in both DREQ and DREP messages.
诊断对象包含DREQ和DREP消息中的公共诊断控制信息。
o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1
o IPv4诊断对象：类=30，C类型=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-RSVP-hops | RSVP-hop-count| Reserved |MF|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+---------------+---------------+---------------+---------------+
| Path MTU | Fragment Offset |
+---------------+---------------+---------------+---------------+
| LAST-HOP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SENDER_TEMPLATE object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requester FILTER_SPEC object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-RSVP-hops | RSVP-hop-count| Reserved |MF|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+---------------+---------------+---------------+---------------+
| Path MTU | Fragment Offset |
+---------------+---------------+---------------+---------------+
| LAST-HOP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SENDER_TEMPLATE object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requester FILTER_SPEC object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here all IP addresses use the 4 byte IPv4 format, both explicitly in the LAST-HOP Address and by using the IPv4 forms of the embedded FILTER_SPEC and RSVP_HOP objects.
在这里，所有IP地址都使用4字节IPv4格式，既可以在最后一跳地址中显式使用，也可以使用嵌入式筛选器规范和RSVP跳对象的IPv4形式。
o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2
o IPv6诊断对象：Class=30，C-Type=2
The format is the same, except all explicit and embedded IP addresses are 16 byte IPv6 addresses.
格式相同，只是所有显式和嵌入式IP地址都是16字节IPv6地址。
The fields are as follows:
字段如下所示：
Max-RSVP-hops
最大RSVP跳数
An octet specifying the maximum number of RSVP hops over which information will be collected. If an error condition in the middle of the path prevents the DREQ packet from reaching the specified ending node, the Max-RSVP-hops field may be used to perform an expanding-length search to reach the point just before
一个八位字节，指定将在其上收集信息的最大RSVP跳数。如果路径中间的错误条件阻止DRIQ分组到达指定的结束节点，则可以使用最大RSVP跳变字段来执行扩展长度搜索以达到刚才的点。
the problem. If this value is 1, the starting node and the ending node of the query will be the same. If it is zero, there is no hop limit.
这个问题。如果该值为1，则查询的开始节点和结束节点将相同。如果为零，则没有跃点限制。
RSVP-hop-count
RSVP跳数
Records the number of RSVP hops that have been traversed so far. If the starting and ending nodes are the same, this value will be 1 in the resulting DREP message.
记录到目前为止已通过的RSVP跳数。如果起始节点和结束节点相同，则在生成的DREP消息中，该值将为1。
Fragment Offset
碎片偏移量
Indicates where this DREP fragment belongs in the complete DREP message, measured in octets. The first fragment has offset zero. Fragment Offset is used also to determine if a DREQ message containing zero DIAG_RESPONSE objects should be processed at an RSVP capable node.
指示此DREP片段在完整DREP消息中所属的位置（以八位字节为单位）。第一个片段的偏移量为零。片段偏移量还用于确定是否应在支持RSVP的节点上处理包含零DIAG_响应对象的DREQ消息。
MF flag
MF标志
Flag means "more fragments". It must be set to zero (0) in all DREQ messages. It must be set to one (1) in all DREP packets that carry partial results and are returned by intermediate nodes due to the MTU limit. When the DREQ message is converted to a DREP message in the ending node, the MF flag must remain zero.
标志的意思是“更多的碎片”。在所有DREQ消息中，必须将其设置为零（0）。由于MTU限制，在所有携带部分结果并由中间节点返回的DREP数据包中，必须将其设置为一（1）。在结束节点中将DREQ消息转换为DREP消息时，MF标志必须保持为零。
Request ID
请求ID
Identifies an individual DREQ message and the corresponding DREP message (or all the fragments of the reply message).
标识单个DREQ消息和相应的DREP消息（或回复消息的所有片段）。
One possible way to define the Request ID would use 16 bits to specify the ID of the process making the query and 16 bits to distinguish different queries from this process.
定义请求ID的一种可能方法是使用16位指定进行查询的进程的ID，并使用16位区分不同的查询与此进程。
Path MTU
路径MTU
Specifies a default MTU size in octets for DREP and DREQ messages. This value should not be smaller than the size of the "base" DREQ packet. A "base" DREQ packet is one that contains a Common Header, a Session object, a Next-Hop RSVP_HOP object, a DIAGNOSTIC object, an empty ROUTE object and a single default DIAG_RESPONSE (see below). The assumption made here is that a diagnostic packet of this size can always be forwarded without IP fragmentation.
指定DREP和DREQ消息的默认MTU大小（以八位字节为单位）。此值不应小于“基本”DREQ数据包的大小。“基本”DREQ数据包包含公共报头、会话对象、下一跳RSVP_-Hop对象、诊断对象、空路由对象和单个默认诊断响应（见下文）。这里的假设是，这种大小的诊断数据包总是可以在没有IP碎片的情况下转发。
LAST-HOP Address
最后一跳地址
The IP address of the LAST-HOP node. The DREQ message starts collecting information at this node and proceeds toward the sender.
最后一跳节点的IP地址。DREQ消息在此节点开始收集信息，并向发送方发送。
SENDER_TEMPLATE object
发送方模板对象
This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and the port of a sender for the session being diagnosed. The DREQ packet is forwarded hop-by-hop towards this address.
此IPv4/IPv6发送方\模板对象包含被诊断会话的发送方的IP地址和端口。DREQ数据包逐跳转发到此地址。
Requester FILTER_SPEC Object
请求者筛选器\u规范对象
This IPv4/IPv6 FILTER_SPEC object contains the IP address and the port from which the request originated and to which the DREP message(s) should be sent.
此IPv4/IPv6筛选器_SPEC对象包含IP地址和端口，请求从该端口发起，DREP消息应发送到该端口。
o DIAG_SELECT Class = 33, C-Type = 1.
o 诊断选择类别=33，C型=1。
A Diagnostic message may optionally contain a DIAG_SELECT object to specify which specific RSVP objects should be reported in a DIAG_RESPONSE object. In the absence of a DIAG_SELECT object, the DIAG_RESPONSE object added by the node will contain a default set of object types (see DIAG_RESPONSE object below).
诊断消息可以选择性地包含DIAG_SELECT对象，以指定应在DIAG_响应对象中报告哪些特定RSVP对象。如果没有DIAG_SELECT对象，则节点添加的DIAG_响应对象将包含一组默认的对象类型（请参见下面的DIAG_响应对象）。
The DIAG_SELECT object contains a list of [Class, C-type] pairs, in the following format:
DIAG_SELECT对象包含以下格式的[Class，C-type]对列表：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a DIAG_SELECT object is included in a DREQ message, each RSVP node along the path will add a DIAG_RESPONSE object containing response objects (see below) whose classes and C-Types match entries in the DIAG_SELECT list (and are from matching path and reservation state). A C-type octet of zero is a 'wildcard', matching any C-Type associated with the associated class.
当DREQ消息中包含DIAG_SELECT对象时，路径上的每个RSVP节点将添加一个DIAG_响应对象，该对象包含响应对象（见下文），其类和C类型与DIAG_SELECT列表中的条目匹配（并且来自匹配路径和保留状态）。零的C类型八位字节是一个“通配符”，匹配与关联类关联的任何C类型。
Depending on the type of objects requested, a node can find the associated information in the path or reservation state stored for the session described in the SESSION object. Specifically, information for the RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC objects can be extracted from the node's path state, while information for the FLOWSPEC, FILTER_SPEC, CONFIRM, STYLE and SCOPE objects can be found in the node's reservation state (if existent).
根据请求的对象类型，节点可以在会话对象中描述的会话存储的路径或保留状态中查找相关信息。具体而言，可以从节点的路径状态中提取RSVP_-HOP、SENDER_-TEMPLATE、SENDER_-TSPEC、ADSPEC对象的信息，而FLOWSPEC、FILTER_-SPEC、CONFIRM、STYLE和SCOPE对象的信息可以在节点的保留状态（如果存在）中找到。
If the number of [Class, C-Type] pairs is odd, the last two octets of the DIAG_SELECT object must be zero. A maximum DIAG_SELECT object is one that contains the [Class, C-type] pairs for all the RSVP objects that can be requested in a Diagnostic query.
如果[Class，C-Type]对的数量为奇数，则DIAG_SELECT对象的最后两个八位字节必须为零。最大DIAG_SELECT对象包含诊断查询中可请求的所有RSVP对象的[Class，C-type]对。
A diagnostic message may contain a ROUTE object, which is used to record the route of the DREQ message and as a source route for returning the DREP message(s) hop-by-hop.
诊断消息可包含路由对象，该对象用于记录DREQ消息的路由，并作为逐跳返回DREP消息的源路由。
o IPv4 ROUTE object: Class = 31, C-Type = 1.
o IPv4路由对象：Class=31，C-Type=1。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | R-pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ RSVP Node List |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | R-pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ RSVP Node List |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message signifies how the reply should be returned. If it does not exist in the DREQ packet then DREP packets should be sent to the requester directly. If it does exist, DREP packets must be returned hop-by-hop along the reverse path to the LAST-HOP node and thence to the requester node.
此消息表示应如何返回回复。如果DREQ数据包中不存在DREP数据包，则DREP数据包应直接发送给请求者。如果DREP数据包确实存在，则必须沿反向路径逐跳返回到最后一跳节点，然后再返回到请求者节点。
An empty ROUTE object is one that has an empty RSVP Node list and R-pointer is equal to zero.
空路由对象是具有空RSVP节点列表且R指针等于零的对象。
RSVP Node List
RSVP节点列表
A list of RSVP node IPv4 addresses. The number of addresses in this list can be computed from the object size.
RSVP节点IPv4地址的列表。此列表中的地址数可以根据对象大小计算。
R-pointer
R指针
Used in DREP messages only (see Section 4.2 for details), but it is incremented as each hop adds its incoming interface address in the ROUTE object.
仅在DREP消息中使用（有关详细信息，请参见第4.2节），但随着每个跃点在ROUTE对象中添加其传入接口地址，该值会增加。
o IPv6 ROUTE object: Class = 31, C-Type = 2
o IPv6路由对象：Class=31，C-Type=2
The same, except RSVP Node List contains IPv6 addresses.
相同，但RSVP节点列表包含IPv6地址除外。
In a DREQ message, RSVP Node List specifies all RSVP hops between the LAST-HOP address specified in the DIAGNOSTIC object, and the last RSVP node the DREQ message has visited. In a DREP message, RSVP Node List specifies all RSVP hops between the LAST-HOP and the node that returns this DREP message.
在DREQ消息中，RSVP节点列表指定诊断对象中指定的最后一跳地址与DREQ消息访问的最后一个RSVP节点之间的所有RSVP跳。在DREP消息中，RSVP节点列表指定最后一跳和返回此DREP消息的节点之间的所有RSVP跳。
Each RSVP node attaches a DIAG_RESPONSE object to each DREQ message it receives, before forwarding the message. The DIAG_RESPONSE object contains the state to be reported for this node. It has a fixed-format header and then a variable list of RSVP state objects, or "response objects".
在转发消息之前，每个RSVP节点将一个DIAG_响应对象附加到它接收的每个DREQ消息。DIAG_响应对象包含要为此节点报告的状态。它有一个固定格式的标题，然后是RSVP状态对象的变量列表，或“响应对象”。
o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1.
o IPv4诊断响应对象：类=32，C类型=1。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DREQ Arrival Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous-RSVP-Hop Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D-TTL |M|R-err| K | Timer value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (optional) TUNNEL object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Response objects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DREQ Arrival Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous-RSVP-Hop Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D-TTL |M|R-err| K | Timer value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (optional) TUNNEL object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Response objects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2.
o IPv6诊断响应对象：Class=32，C-Type=2。
This object has the same format, except that all explicit and embedded IP addresses are IPv6 addresses.
此对象具有相同的格式，只是所有显式和嵌入式IP地址都是IPv6地址。
The fields are as follows:
字段如下所示：
DREQ Arrival Time
DREQ到达时间
A 32-bit NTP timestamp specifying the time the DREQ message arrived at this node. The 32-bit form of an NTP timestamp consists of the middle 32 bits of the full 64-bit form, that is, the low 16 bits of the integer part and the high 16 bits of the fractional part.
32位NTP时间戳，指定DREQ消息到达此节点的时间。NTP时间戳的32位形式由完整64位形式的中间32位组成，即整数部分的低16位和小数部分的高16位。
Incoming Interface Address
传入接口地址
Specifies the IP address of the interface on which messages from the sender are expected to arrive, or 0 if unknown.
指定预期发件人的消息将到达的接口的IP地址，如果未知，则指定0。
Outgoing Interface Address
传出接口地址
Specifies the IP address of the interface through which the DREQ message arrived and to which messages from the given sender and for the specified session address flow, or 0 if unknown.
指定DREQ消息到达的接口的IP地址，以及来自给定发送方和指定会话地址的消息流向的IP地址，如果未知，则指定0。
Previous-RSVP-Hop Router Address
以前的RSVP跃点路由器地址
Specifies the IP address from which this node receives RSVP PATH messages for this source, or 0 if unknown. This is also the interface to which the DREQ will be forwarded.
指定此节点从中接收此源的RSVP路径消息的IP地址，如果未知，则指定0。这也是DREQ将转发到的接口。
D-TTL
D-TTL
The number of IP hops this DREQ message traveled from the down-stream RSVP node to the current node.
此DREQ消息从下游RSVP节点传输到当前节点的IP跃点数。
M flag
M旗
A single-bit flag which indicates whether the reservation described by the response objects is merged with reservations from other down-stream interfaces when being forwarded upstream.
一个单位标志，指示响应对象描述的保留在向上游转发时是否与其他下游接口的保留合并。
R-error
R误差
A 3-bit field that indicates error conditions at a node. Currently defined values are:
一个3位字段，指示节点处的错误情况。当前定义的值为：
0x00: no error 0x01: No PATH state 0x02: packet too big 0x04: ROUTE object too big
0x00:无错误0x01:无路径状态0x02:数据包太大0x04:路由对象太大
K
K
The refresh timer multiple (defined in [RSVP]).
刷新计时器为倍数（在[RSVP]中定义）。
Timer value
定时器值
The local refresh timer value in seconds.
本地刷新计时器值（以秒为单位）。
The set of response objects to be included at the end of the DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is present. If no DIAG_SELECT object is present, the response objects belong to the default list of classes:
要包含在DIAG_响应对象末尾的响应对象集由DIAG_SELECT对象（如果存在）确定。如果不存在DIAG_SELECT对象，则响应对象属于默认的类列表：
SENDER_TSPEC object FILTER_SPEC object FLOWSPEC object STYLE object
发送方\u TSPEC对象过滤器\u等级库对象FLOWSPEC对象样式对象
Any C-Type present in the local RSVP state will be used. These response objects may be in any order but they must all be at the end of the DIAG_RESPONSE object.
将使用本地RSVP状态下的任何C-Type。这些响应对象可以按任何顺序排列，但它们必须全部位于DIAG_响应对象的末尾。
A default DIAG_RESPONSE object is one containing the default list of classes described above.
默认的DIAG_响应对象包含上述类的默认列表。
The optional TUNNEL object should be inserted when a DREQ message arrives at an RSVP node that acts as a tunnel exit point.
当DREQ消息到达充当隧道出口点的RSVP节点时，应插入可选的隧道对象。
The TUNNEL object provides the mapping between the end-to-end RSVP session that is being diagnosed and the RSVP session over the tunnel. This mapping information allows the diagnosis client to conduct diagnosis over the involved tunnel session, by invoking a separate Diagnostic query for the corresponding Tunnel Session and Tunnel Sender. Keep in mind, however, that multiple end-to-end sessions may all map to one pre-configured tunnel session that may have totally different parameter settings.
隧道对象提供正在诊断的端到端RSVP会话与隧道上的RSVP会话之间的映射。此映射信息允许诊断客户端通过调用对应隧道会话和隧道发送方的单独诊断查询，在涉及的隧道会话上执行诊断。但是，请记住，多个端到端会话可能都映射到一个预配置的隧道会话，该会话可能具有完全不同的参数设置。
The tunnel object is defined in the RSVP Tunnel Specification [RSVPTUN].
隧道对象在RSVP隧道规范[RSVPTUN]中定义。
DREQ messages are forwarded hop-by-hop via unicast from the LAST-HOP address to the Sender address, as specified in the DIAGNOSTIC object. If an RSVP capable node, other than the LAST-HOP node, receives a DREQ message that contains no DIAG_RESPONSE objects and has a zero
按照诊断对象中的指定，DREQ消息通过单播逐跳从最后一跳地址转发到发送方地址。如果支持RSVP的节点（最后一跳节点除外）接收到一条DREQ消息，该消息不包含任何DIAG_响应对象，并且具有零
Fragment Offset, the node should forward the DREQ packet towards the LAST-HOP without doing any of the processing mentioned below. The reason is that such conditions apply only for nodes downstream of the LAST-HOP where no information should be collected.
片段偏移，则节点应将DREQ数据包转发到最后一跳，而无需执行以下任何处理。原因是，此类条件仅适用于不应收集信息的最后一跳下游节点。
Processing begins when a DREQ message, DREQ_in, arrives at a node.
当DREQ消息DREQ_in到达节点时，处理开始。
1. Create a new DIAG_RESPONSE object. Compute the IP hop count from the previous RSVP hop. This is done by subtracting the value of the TTL value in the IP header from Send_TTL in the RSVP common header. Save the result in the D-TTL field of the DIAG_RESPONSE object.
1. 创建新的DIAG_响应对象。从上一个RSVP跃点计算IP跃点计数。这是通过从RSVP公共头中的发送TTL减去IP头中的TTL值来实现的。将结果保存在DIAG_响应对象的D-TTL字段中。
2. Set the DREQ Arrival Time and the Outgoing Interface Address in the DIAG_RESPONSE object. If this node is the LAST-HOP, then the Out- going Interface Address field in the DIAG_RESPONSE object contains the following value depending on the session being diagnosed.
2. 在DIAG_响应对象中设置DREQ到达时间和传出接口地址。如果此节点是最后一跳，则DIAG_响应对象中的Out-Out Interface Address字段包含以下值，具体取决于正在诊断的会话。
* If the session in question is a unicast session, then the Out-going Interface Address field contains the address of the interface LAST-HOP uses to send PATH messages and data to the receiver specified by the session address.
* 如果所讨论的会话是单播会话，则Out-Out Interface Address字段包含LAST-HOP用于向会话地址指定的接收器发送路径消息和数据的接口地址。
* Otherwise, if it is a multicast session and there is at least one receiver for this session, LAST_HOP should use the address of one of local interfaces used to reach one of the receivers.
* 否则，如果它是一个多播会话，并且该会话至少有一个接收器，则最后一跳应该使用用于到达其中一个接收器的一个本地接口的地址。
* Otherwise Outgoing Interface Address should be zero.
* 否则，传出接口地址应为零。
3. Increment the RSVP-hop-count field in the DIAGNOSTIC message object by one.
3. 将诊断消息对象中的RSVP跃点计数字段增加1。
4. If no PATH state exists for the specified session, set R-error = 0x01 (No PATH state) and goto step 7.
4. 如果指定会话不存在路径状态，请设置R-error=0x01（无路径状态）并转到步骤7。
5. Set the rest of the fields in the DIAG_RESPONSE object. If DREQ_in contains a DIAG_SELECT object, the response object classes are those specified in the DIAG_SELECT; otherwise, they are SENDER_TSPEC, STYLE, and FLOWSPEC objects. If no reservation state exists for the specified RSVP session, the DIAG_RESPONSE object will contain no FLOWSPEC, FILTER_SPEC or STYLE object. If neither PATH nor reservation state exists for the specified RSVP session, then no response objects will be appended to the DIAG_RESPONSE object.
5. 设置DIAG_响应对象中的其余字段。如果DREQ_in包含DIAG_SELECT对象，则响应对象类为DIAG_SELECT中指定的类；否则，它们是SENDER_TSPEC、STYLE和FLOWSPEC对象。如果指定的RSVP会话不存在保留状态，则DIAG_响应对象将不包含FLOWSPEC、FILTER_SPEC或STYLE对象。如果指定的RSVP会话既不存在路径也不存在保留状态，则不会向DIAG_响应对象追加响应对象。
6. If RSVP-hop-count is less than Max-RSVP-hops and this node is not the sender, then the DREQ is eligible for forwarding; set the Path MTU to the min of the Path MTU and the MTU size of the incoming interface for the sender being diagnosed.
6. 如果RSVP跳数小于最大RSVP跳数，且该节点不是发送方，则DREQ符合转发条件；将路径MTU设置为被诊断发送方的路径MTU的最小值和传入接口的MTU大小。
7. If the size of DREQ_in plus the size of the new DIAG_RESPONSE object plus the size of an IP address (if a ROUTE object exists and R-error= 0) is larger than Path MTU, then the new diagnostic message will be too large to be forwarded or returned without fragmentation; set the "packet too big" (0x02) error bit in DIAG_RESPONSE and goto Step SD1 in Send_DREP (below).
7. 如果DREQ_in的大小加上新的DIAG_响应对象的大小加上IP地址的大小（如果存在路由对象且R-error=0）大于Path MTU，则新的诊断消息将太大，无法在没有碎片的情况下转发或返回；在DIAG_响应中设置“数据包太大”（0x02）错误位，然后转到Send_DREP（以下）中的步骤SD1。
8. If the "No PATH state" (0x01) error bit is set or if RSVP-hop-count is equal to Max-RSVP-hops or if this node is the sender, then the DREQ cannot be forwarded further; goto Step 10.
8. 如果设置了“无路径状态”（0x01）错误位，或者如果RSVP跳数等于最大RSVP跳数，或者如果该节点是发送方，则DREQ无法进一步转发；转到第10步。
9. Forward the DREQ towards the sender, as follows. If a ROUTE object exists, append the "Incoming Interface Address" to the end of the ROUTE object and increment R-Pointer by one. Update the Next-Hop RSVP_HOP object, append the new DIAG_RESPONSE object to the list of DIAG_RESPONSE object, and update the message length field in the RSVP common header accordingly. Finally, recompute the checksum, forward DREQ_in to the next hop towards the sender, and return.
9. 将DREQ转发给发送方，如下所示。如果存在路由对象，则将“传入接口地址”附加到路由对象的末尾，并将R指针递增1。更新下一跳RSVP_-Hop对象，将新的DIAG_响应对象附加到DIAG_响应对象列表中，并相应地更新RSVP公共头中的消息长度字段。最后，重新计算校验和，将DREQ_转发到下一个向发送方的跃点，然后返回。
10. Turn the DREQ into a DREP and return to the requester, as follows. Append the DIAG_RESPONSE object to the end of DREQ_in and update the packet length. If a ROUTE object is present in the message, decrement the R-pointer and set target address to the last address in the ROUTE object, otherwise set target address to the requester address. Change the Type Field in the Common header from DREQ to DREP. Finally, recompute the checksum, send the DREP to the target address, and return. Note that the MF bit must be off in this case.
10. 将DREQ转换为DREP并返回给请求者，如下所示。将DIAG_响应对象附加到DREQ_in的末尾，并更新数据包长度。如果消息中存在路由对象，则减小R指针并将目标地址设置为路由对象中的最后一个地址，否则将目标地址设置为请求者地址。将公共标头中的类型字段从DREQ更改为DREP。最后，重新计算校验和，将DREP发送到目标地址，然后返回。注意，在这种情况下，MF位必须关闭。
Send_DREP:
发送地址：
This sequence is entered if the DREQ message augmented with the new DIAG_RESPONSE object is too large to be forwarded towards the sender or, if it is not eligible for forwarding, too large to be returned as a DREP.
如果添加了新DIAG_响应对象的DREQ消息太大，无法转发给发送方，或者太大，无法作为DREP返回，则输入此序列。
SD1. Make a copy of DREQ_in and change the message type field from DREQ to DREP. Trim all DIAG_RESPONSE objects from DREQ_in and adjust the Fragment Offset. The DREP message contains the DIAG_RESPONSE objects accumulated by prior nodes.
SD1。在中复制DREQ_，并将消息类型字段从DREQ更改为DREP。从DREQ_中修剪所有DIAG_响应对象，并调整片段偏移。DREP消息包含先前节点累积的DIAG_响应对象。
SD2. Send the DREP message towards the requester, as follows. If a ROUTE object is present in the DREP message, decrement the R-pointer and set target address to the last address in the ROUTE object, otherwise set target address to the requester address. Set the MF bit, recompute the checksum and send the DREP message back to the target address.
SD2。向请求者发送DREP消息，如下所示。如果DREP消息中存在路由对象，则减小R指针并将目标地址设置为路由对象中的最后一个地址，否则将目标地址设置为请求者地址。设置MF位，重新计算校验和，并将DREP消息发送回目标地址。
SD3. If the reduced size of DREQ_in plus the size of DIAG_RESPONSE plus the size of an IP address (if a ROUTE object exists) is smaller than or equal to Path MTU, then return to Step 8 of the main DREQ processing sequence above.
SD3。如果DREQ_in的缩减大小加上DIAG_响应的大小加上IP地址的大小（如果存在路由对象）小于或等于Path MTU，则返回到上面主DREQ处理序列的步骤8。
SD4. If a ROUTE object exists, replace the ROUTE object in DREQ_in with an empty ROUTE object and turn on the "ROUTE object too big" (0x04) error bit in the DIAG_RESPONSE. In either case, return to Step 8 of the main DREQ processing sequence above.
SD4。如果存在路由对象，请将DREQ_in中的路由对象替换为空路由对象，并在DIAG_响应中启用“路由对象太大”（0x04）错误位。在任何一种情况下，返回到上面的主DREQ处理序列的步骤8。
When a ROUTE object is present, DREP messages are forwarded hop-by-hop towards the requester, by reversing the route as listed in the ROUTE object. Otherwise, DREP messages are sent directly to the original requester.
当存在ROUTE对象时，DREP消息通过按照ROUTE对象中列出的反向路由逐跳转发给请求者。否则，DREP消息将直接发送给原始请求者。
When a node receives a DREP message, it simply decreases R-pointer by one (address length), recomputes the checksum and forwards the message to the address pointed to by R-pointer in the route list. If a node, other than the LAST-HOP, receives a DREP packet where R-pointer is equal to zero, it must send it directly to the requester.
当节点接收到DREP消息时，它只需将R指针减少1（地址长度），重新计算校验和，并将消息转发到路由列表中R指针指向的地址。如果除最后一跳之外的节点接收到R指针等于零的DREP数据包，则它必须将其直接发送给请求者。
When the LAST-HOP node receives a DREP message, it sends the message to the requester.
当最后一跳节点接收到DREP消息时，它将消息发送给请求者。
Because the DREQ message carries the allowed MTU size of previous hops that the DREP messages will later traverse, this unique feature allows easy semantic fragmentation as described above. Whenever the DREQ message approaches the size of Path MTU, it can be trimmed before being forwarded again.
由于DREQ消息承载DREP消息稍后将遍历的先前跳的允许MTU大小，因此此独特功能允许如上所述的简单语义分段。每当DREQ消息接近路径MTU的大小时，可以在再次转发之前对其进行修剪。
When a requester sends a DREQ message, the Path MTU field in the DIAGNOSTIC object can be set to a configured default value. It is possible that the original Path MTU value is chosen larger than the actual MTU value along some portion of the path being traced. Therefore each intermediate RSVP node must check the MTU value when processing a DREQ message. If the specified MTU value is larger than
当请求者发送DREQ消息时，可以将诊断对象中的Path MTU字段设置为配置的默认值。可能选择的原始路径MTU值大于沿着被跟踪路径的某个部分的实际MTU值。因此，在处理DREQ消息时，每个中间RSVP节点必须检查MTU值。如果指定的MTU值大于
the MTU of the incoming interface (that the DREQ message will be forwarded to), the node changes the MTU value in the header to the smaller value.
传入接口的MTU（DREQ消息将转发到该接口），节点将头中的MTU值更改为较小的值。
Whenever a DREQ message size becomes larger than the Path MTU value, an intermediate RSVP node makes a copy of the message, converts it to a DREP message to send back, and then trims off the partial results from the DREQ message. If in this case also the DREQ cannot be forwarded upstream due to a large ROUTE object, the "ROUTE object too big" is set and the ROUTE object is trimmed. As a result of the ROUTE object trimming, DREP(s) will come hop-by-hop up to this node and will then immediately be forwarded to the requester address.
每当DREQ消息大小大于Path MTU值时，中间RSVP节点都会复制该消息，将其转换为DREP消息以发送回，然后修剪DREQ消息的部分结果。如果在这种情况下，由于较大的路由对象，DREQ也无法向上游转发，则设置“路由对象太大”，并修剪路由对象。作为路由对象修剪的结果，DREP将一跳一跳地到达该节点，然后将立即转发到请求者地址。
Even if the steps shown above are followed there are a few cases where fragmentation at the IP layer will happen. For example, non-RSVP hops with smaller MTUs may exist before LAST-HOP is reached, or if the response is sent directly back to requester (as opposed to hop by hop) the DREP may take a different route to the requester than the DREQ took from the requester. Another case is when there exists a link with MTU smaller than the minimum Path MTU value defined in Section 3.3.
即使遵循上面所示的步骤，也有一些情况会在IP层发生碎片。例如，在到达最后一跳之前，可能存在MTU较小的非RSVP跳，或者如果响应直接发送回请求者（与逐跳相反），则DREP可能采用与从请求者获取的DREQ不同的路由到达请求者。另一种情况是存在MTU小于第3.3节中定义的最小路径MTU值的链路。
If an error condition prevents a DREP message from being forwarded further, the message is simply dropped.
如果错误条件阻止进一步转发DREP消息，则只需删除该消息。
If an error condition, such as lack of PATH state, prevents a DREQ message from being forwarded further, the node must change the current message to DREP type and return it to the response address.
如果错误条件（如缺少路径状态）阻止DREQ消息进一步转发，则节点必须将当前消息更改为DREP类型，并将其返回到响应地址。
Firewalls may cause problems in diagnostic message forwarding. Let us look at two different cases.
防火墙可能会导致诊断消息转发出现问题。让我们看两种不同的情况。
First, let us assume that the querier resides on a receiving host of the session to be examined. In this case, firewalls should not prevent the forwarding of the diagnostic messages in a hop-by-hop manner, assuming that proper holes have been punched on the firewall to allow hop-by-hop forwarding of other RSVP messages. The querier may start by not including a ROUTE object, which can give a faster response delivery and reduced overhead at intermediate nodes. However if no response is received, the querier may resend the DREQ message with a ROUTE object, specifying that a hop-by-hop reply should be sent.
首先，假设查询器驻留在要检查的会话的接收主机上。在这种情况下，防火墙不应阻止以逐跳方式转发诊断消息，前提是在防火墙上打孔以允许逐跳转发其他RSVP消息。查询者可以从不包括路由对象开始，这可以提供更快的响应传递，并减少中间节点的开销。但是，如果没有收到响应，查询者可以使用路由对象重新发送DREQ消息，指定应发送逐跳回复。
If the requester is a third party host and is separated from the LAST-HOP address by a firewall (either the requester is behind a firewall, or the LAST-HOP is a node behind a firewall, or both), at this time we do not know any other solution but to change the LAST-HOP to a node that is on the same side of the firewall as the requester.
如果请求者是第三方主机，并且被防火墙与最后一个跃点地址隔开（请求者在防火墙后面，或者最后一个跃点是防火墙后面的节点，或者两者都是），此时我们不知道任何其他解决方案，只知道将最后一个跃点更改为与请求者位于防火墙同一侧的节点。
One can easily collect information about the current timer value at each RSVP hop along the way. This will be very helpful in situations when the reservation state goes up and down frequently, to find out whether the state changes are due to improper setting of timer values, or K values (when across lossy links), or frequent routing changes.
一路上每个RSVP跳都可以很容易地收集关于当前计时器值的信息。这在保留状态频繁上升和下降的情况下非常有用，以确定状态更改是否是由于计时器值或K值（跨有损链路时）设置不当，或频繁路由更改造成的。
The D-TTL field in each DIAG_RESPONSE object shows the number of routing hops between adjacent RSVP nodes. Therefore any value greater than one indicates a non-RSVP cloud in between. Together with the arrival timestamps (assuming NTP works), this value can also give some vague, though not necessarily accurate, indication of how big that cloud might be. One might also find out all the intermediate non-RSVP nodes by running either unicast or multicast trace route.
每个DIAG_响应对象中的D-TTL字段显示相邻RSVP节点之间的路由跳数。因此，任何大于1的值都表示介于两者之间的非RSVP云。与到达时间戳（假设NTP有效）一起，该值还可以给出云可能有多大的模糊指示，尽管不一定准确。还可以通过运行单播或多播跟踪路由查找所有中间非RSVP节点。
The flowspec value in a DIAG_RESPONSE object specifies the amount of resources being reserved for the data stream defined by the filter spec in the same data block. When this value of adjacent DIAG_RESPONSE objects differs, that is, a downstream node Rd has a smaller value than its immediate upstream node Ru, it indicates a merge of reservation with RSVP request(s) from other down stream interface(s) at Rd. Further, in case of SE style reservation, one can examine how the different SE scopes get merged at each hop.
DIAG_响应对象中的flowspec值指定为同一数据块中过滤器规范定义的数据流保留的资源量。当相邻DIAG_响应对象的此值不同时，即下游节点Rd的值小于其直接上游节点Ru的值，则表示保留与Rd处其他下游接口的RSVP请求合并。此外，在SE样式保留的情况下，可以检查不同的SE作用域如何在每个跃点处合并。
In particular, if a receiver sends a DREQ message before sending its own reservation, it can discover (1) how many RSVP hops there are along the path between the specified sender and itself, (2) how many of the hops already have some reservation by other receivers, and (3) possibly a rough prediction of how its reservation request might get merged with other existing ones.
特别是，如果接收器在发送其自己的保留之前发送DREQ消息，它可以发现（1）在指定的发送者和自身之间的路径上有多少RSVP跳，（2）有多少跳已经被其他接收器保留，以及（3）可能是对其预订请求如何与其他现有请求合并的粗略预测。
In addition to examining the state of a working reservation, RSVP diagnostic messages are more likely to be invoked when things are not working correctly. For example, a receiver has reserved an adequate pipe for a specified incoming data stream, yet the observed delay or loss ratio is much higher than expected. In this case the receiver can use the diagnostic facility to examine the reservation state at each RSVP hop along the way to find out whether the RSVP state is set up correctly, whether there is any black-hole along the way that caused RSVP message losses, or whether there are non-RSVP clouds, and where they are, that may have caused the performance problem.
除了检查工作保留的状态外，当工作不正常时，更有可能调用RSVP诊断消息。例如，接收器为指定的传入数据流保留了足够的管道，但观察到的延迟或丢失率远远高于预期。在这种情况下，接收器可以使用诊断设备检查沿途每个RSVP跃点的保留状态，以确定RSVP状态设置是否正确，沿途是否存在导致RSVP消息丢失的黑洞，或者是否存在非RSVP云，以及它们的位置，这可能导致了性能问题。
Since this diagnosis facility was developed and added to RSVP after a number of RSVP implementations were in place, it is possible, or even likely, that when performing RSVP diagnosis, one may encounter one or more RSVP-capable nodes that do not understand diagnostic messages and drop them. When this happens, the invoking client will get no response from its requests.
由于该诊断设施是在许多RSVP实施到位后开发并添加到RSVP的，因此在执行RSVP诊断时，可能会遇到一个或多个不理解诊断消息的支持RSVP的节点并丢弃它们。发生这种情况时，调用客户端将不会从其请求中得到响应。
One way to by-pass such "legacy" RSVP nodes is to perform RSVP diagnosis repeatedly, guided by information from traceroute, or mtrace in case of multicast. When an RSVP diagnostic query times out (see next section), one may first use traceroute to get the list of nodes along the path, and then gradually increase the value of Max-RSVP-hops field in the DREQ message, starting from a low value until one no longer receives a response. One can then try RSVP diagnosis again by starting with the first node (which is further upstream towards the sender) after the unresponding one.
绕过此类“遗留”RSVP节点的一种方法是在跟踪路由或多播情况下的mtrace信息的指导下重复执行RSVP诊断。当RSVP诊断查询超时（见下一节）时，可以首先使用traceroute获取路径上的节点列表，然后逐渐增加DREQ消息中最大RSVP跳数字段的值，从低值开始，直到不再接收响应为止。然后，可以从非响应节点之后的第一个节点（更靠近发送方的上游）开始，再次尝试RSVP诊断。
There are two problem with the method mentioned above in the case of unicast sessions. Both problems are related to the fact that traceroute information provides the path from the requester to the sender. The first problem is that the LAST-HOP may not be on the path from the requester to the sender. In this case we can get information only from the portion of the path from the LAST-HOP to the sender which intersects with the path from the requester to the sender. If routers that are not on the intersection of the two paths don't have PATH state for the session being diagnosed then they will reply with R-error=0x01. The requester can overcome this problem by sending a DREQ to every router on the path (from itself to the sender) until it reaches the first router that belongs to the path from the sender to the LAST-HOP.
在单播会话的情况下，上述方法存在两个问题。这两个问题都与跟踪路由信息提供从请求者到发送者的路径有关。第一个问题是，最后一跳可能不在从请求者到发送者的路径上。在这种情况下，我们只能从从最后一跳到发送方的路径部分获取信息，该部分与从请求方到发送方的路径相交。如果不在两条路径交叉点上的路由器没有被诊断会话的路径状态，那么它们将用R-error=0x01进行回复。请求者可以通过向路径（从自身到发送者）上的每个路由器发送DREQ，直到到达属于从发送者到最后一跳的路径的第一个路由器，从而克服这个问题。
The second problem is that traceroute provides the path from the requester to the sender which, due to routing asymmetries, may be different than the path traffic from the sender to the LAST-HOP uses. There is (at least) one case where this asymmetry will cause the diagnosis to fail. We present this case below.
第二个问题是，traceroute提供了从请求者到发送者的路径，由于路由不对称，该路径可能不同于从发送者到最后一跳使用的路径流量。有（至少）一种情况下，这种不对称会导致诊断失败。我们在下面介绍这个案例。
Downstream Path Sender
__ __ __ __
Receiver +------| |<------| |<-- ...---| |-----| |
__ __ / |__| |__| |__| |__|
| |--....--|X |_/ ^
|__| |__| \ Router B |
Black \ __ |
Hole +----->| |---->---+
|__| Upstream Path
Downstream Path Sender
__ __ __ __
Receiver +------| |<------| |<-- ...---| |-----| |
__ __ / |__| |__| |__| |__|
| |--....--|X |_/ ^
|__| |__| \ Router B |
Black \ __ |
Hole +----->| |---->---+
|__| Upstream Path
Router A
路由器A
Figure 2
图2
Here the first hop upstream of the black hole is different on the upstream path and the downstream path. Traceroute will indicate router A as the previous hop (instead of router B which is the right one). Sending a DREQ to router A will result in A responding with R-error 0x01 (No PATH State). If the two paths converge again then the requester can use the solution proposed above to get any (partial) information from the rest of the path.
在这里，黑洞上游的第一跳在上游路径和下游路径上是不同的。Traceroute将路由器A指示为前一跳（而不是正确的路由器B）。将DREQ发送到路由器a将导致响应为R错误0x01（无路径状态）。如果这两条路径再次收敛，那么请求者可以使用上面提出的解决方案从路径的其余部分获取任何（部分）信息。
We don't have, for the moment, any complete solutions for the problematic scenarios described here.
对于这里描述的问题场景，我们目前还没有任何完整的解决方案。
6. Comments on Diagnostic Client Implementation.
6. 关于诊断客户端实现的评论。
Following the design principle that nodes in the network should not hold more than necessary state, RSVP nodes are responsible only for forwarding Diagnostic messages and filling DIAG_RESPONSE objects. Additional diagnostic functionality should be carried out by the diagnostic clients. Furthermore, if the diagnostic function is invoked from a third-party host, we should not require that host be running an RSVP daemon to perform the function. Below we sketch out the basic functions that a diagnostic client daemon should carry out.
按照网络中的节点不应持有超过必要状态的设计原则，RSVP节点仅负责转发诊断消息和填充DIAG_响应对象。其他诊断功能应由诊断客户端执行。此外，如果诊断功能是从第三方主机调用的，我们不应该要求该主机运行RSVP守护程序来执行该功能。下面我们简要介绍了诊断客户端守护程序应该执行的基本功能。
1. Take input from the user about the session to be diagnosed, the last-hop and the sender address, the Max-RSVP-hops, and possibly the DIAG_SELECT list, create a DREQ message and send to the LAST-HOP RSVP node using raw IP message with protocol number 46 (RSVP). If the user specified that the response should be sent hop-by-hop include an empty ROUTE object to the
1. 从用户处获取有关要诊断的会话、最后一跳和发送方地址、最大RSVP跳数以及可能的DIAG_SELECT列表的输入，创建DREQ消息，并使用协议号为46（RSVP）的原始IP消息发送到最后一跳RSVP节点。如果用户指定应逐跳发送响应，请将空路由对象包含到
DREQ message sent. Set the Path_MTU to the smaller of the user request and the MTU of the link through which the DREQ will be sent.
DREQ消息已发送。将Path_MTU设置为用户请求和发送DREQ的链路的MTU中的较小者。
The port of the UDP socket on which the Diagnostic Client is listening for replies should be included in the Requester FILTER_SPEC object.
诊断客户端正在侦听答复的UDP套接字端口应包含在请求者筛选器规范对象中。
2. Set a retransmission timer, waiting for the reply (one or more DREP messages). Listen to the specified UDP port for responses from the LAST-HOP RSVP node.
2. 设置重传计时器，等待回复（一条或多条DREP消息）。侦听指定的UDP端口以获取来自最后一跳RSVP节点的响应。
The LAST-HOP RSVP node, upon receiving DREP messages, sends them to the Diagnostic Client as UDP packets, using the port supplied in the Requester FILTER_SPEC object.
最后一跳RSVP节点在接收到DREP消息后，使用请求者筛选器_SPEC对象中提供的端口将它们作为UDP数据包发送到诊断客户端。
3. Upon receiving a DREP message to an outstanding diagnostic request, the client should clear the retransmission timer, check to see if the reply contains the complete result of the requested diagnosis. If so, it should pass the result up to the invoking entity immediately.
3. 在收到针对未完成诊断请求的DREP消息后，客户端应清除重传计时器，检查回复是否包含请求诊断的完整结果。如果是这样，它应该立即将结果传递给调用实体。
4. Reassemble DREP fragments. If the first reply to an outstanding diagnostic request contains only a fragment of the expected result, the client should set up a reassembly timer in a way similar to IP packet reassembly timer. If the timer goes off before all fragments arrive, the client should pass the partial result to the invoking entity.
4. 重新组装DREP碎片。如果对未完成的诊断请求的第一个答复仅包含预期结果的一部分，则客户端应以类似于IP数据包重新组装计时器的方式设置重新组装计时器。如果计时器在所有片段到达之前关闭，则客户端应将部分结果传递给调用实体。
5. Use retransmission and reassembly timers to gracefully handle packet losses and reply fragment scenarios.
5. 使用重传和重新组装计时器优雅地处理数据包丢失和回复片段场景。
In the absence of response to the first diagnostic request, a client should retransmit the request a few times. If all the retransmissions also fail, the client should invoke traceroute or mtrace to obtain the list of hops along the path segment to be diagnosed, and then perform an iteration of diagnosis with increasing hop count as suggested in Section 5.6 in order to cross RSVP-capable but diagnosis-incapable nodes.
在第一个诊断请求没有响应的情况下，客户机应该重新传输请求几次。如果所有重传也失败，则客户端应调用traceroute或mtrace，以获得沿要诊断的路径段的跳数列表，然后按照第5.6节中的建议，通过增加跳数来执行诊断迭代，以便跨支持RSVP但不支持诊断的节点。
6. If all the above efforts fail, the client must notify the invoking entity.
6. 如果上述所有工作都失败，客户机必须通知调用实体。
RSVP Diagnostics, as any other diagnostic tool, can be a security threat since it can reveal possibly sensitive RSVP state information to unwanted third parties.
RSVP诊断与任何其他诊断工具一样，可能是一种安全威胁，因为它可能会将可能敏感的RSVP状态信息泄露给不需要的第三方。
We feel that the threat is minimal, since as explained in the Introduction Diagnostics messages produce no side-effects and therefore they cannot change RSVP state in the nodes. In this respect RSVP Diagnostics is less a security threat than other diagnostic tools and protocols such as SNMP.
我们认为威胁是最小的，因为正如简介中所解释的，诊断消息不会产生任何副作用，因此它们无法更改节点中的RSVP状态。在这方面，RSVP诊断比其他诊断工具和协议（如SNMP）的安全威胁更小。
Furthermore, processing of Diagnostic messages can be disabled if it is felt that is a security threat.
此外，如果认为存在安全威胁，则可以禁用诊断消息的处理。
The idea of developing a diagnostic facility for RSVP was first suggested by Mark Handley of ACIRI. Many thanks to Lee Breslau of AT&T Labs and John Krawczyk of Nortel Networks for their valuable comments on the first draft of this memo. Lee Breslau, Bob Braden, and John Krawczyk contributed further comments after March 1996 IETF. Steven Berson provided valuable comments on various drafts of the memo. Tim Gleeson contributed an extensive list of editorial comments. We would also like to acknowledge Intel for providing a research grant as a partial support for this work. Subramaniam Vincent did most of this work while a graduate research assistant at the USC Information Sciences Institute (ISI).
ACIRI的Mark Handley首先提出了开发RSVP诊断设备的想法。非常感谢AT&T实验室的Lee Breslau和北电网络的John Krawczyk对本备忘录初稿的宝贵意见。Lee Breslau、Bob Braden和John Krawczyk在1996年3月IETF后发表了进一步的评论。史蒂文·贝尔森对备忘录的各种草案提出了宝贵的意见。蒂姆·格雷森（Tim Gleeson）提供了一份广泛的编辑评论清单。我们还要感谢英特尔公司提供研究资助，作为对这项工作的部分支持。Subramaniam Vincent在南加州大学信息科学研究所（ISI）担任研究生研究助理期间完成了大部分工作。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议——第1版功能规范”，RFC 22052997年9月。
[RSVPTUN] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RSVPTUN]Terzis，A.，Krawczyk，J.，Wroclawski，J.和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
Andreas Terzis UCLA 4677 Boelter Hall Los Angeles, CA 90095
加州大学洛杉矶分校安德烈亚斯·特齐斯4677博尔特大厅，加利福尼亚州洛杉矶，邮编90095
Phone: 310-267-2190 EMail: terzis@cs.ucla.edu
电话：310-267-2190电子邮件：terzis@cs.ucla.edu
Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
鲍勃·布拉登南加州信息科学研究所，地址：加利福尼亚州马里纳·德雷市金钟路4676号，邮编：90292
Phone: 310 822-1511 EMail: braden@isi.edu
电话：310 822-1511电子邮件：braden@isi.edu
Subramaniam Vincent Cisco Systems 275, E Tasman Drive, MS SJC04/2/1 San Jose, CA 95134
加利福尼亚州圣何塞市SJC04/2/1号塔斯曼大道东275号Subramaniam Vincent Cisco Systems，邮编95134
Phone: 408 525 3474 EMail: svincent@cisco.com
电话：408 525 3474电子邮件：svincent@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
加利福尼亚州洛杉矶加利福尼亚大学洛杉矶分校张丽霞4531G博尔特大厅，邮编90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
电话：310-825-2695电子邮件：lixia@cs.ucla.edu
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编辑功能的资金目前由互联网协会提供。