Network Working Group L. Berger
Request for Comments: 2961 LabN Consulting, LLC
Category: Standards Track D. Gan
Juniper Networks, Inc.
G. Swallow
Cisco Systems, Inc.
P. Pan
Juniper Networks, Inc.
F. Tommasi
S. Molendini
University of Lecce
April 2001
Network Working Group L. Berger
Request for Comments: 2961 LabN Consulting, LLC
Category: Standards Track D. Gan
Juniper Networks, Inc.
G. Swallow
Cisco Systems, Inc.
P. Pan
Juniper Networks, Inc.
F. Tommasi
S. Molendini
University of Lecce
April 2001
RSVP Refresh Overhead Reduction Extensions
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. The same extensions also support reliable RSVP message delivery on a per hop basis. These extension present no backwards compatibility issues.
本文档描述了一些机制，这些机制可用于减少刷新消息的处理开销要求，消除RSVP（资源保留协议）消息丢失时产生的状态同步延迟，以及在需要时，在不传输整个刷新消息的情况下刷新状态。同样的扩展还支持基于每跳的可靠RSVP消息传递。这些扩展不存在向后兼容性问题。
Table of Contents
目录
1 Introduction and Background ................................2
1.1 Trigger and Refresh Messages ...............................4
2 Refresh-Reduction-Capable Bit ..............................4
3 RSVP Bundle Message ........................................5
3.1 Bundle Header ..............................................5
3.2 Message Formats ............................................6
3.3 Sending RSVP Bundle Messages ...............................7
3.4 Receiving RSVP Bundle Messages .............................8
4 MESSAGE_ID Extension .......................................8
4.1 Modification of Standard Message Formats ...................9
4.2 MESSAGE_ID Objects ........................................10
4.3 MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects ................11
4.4 Ack Message Format ........................................11
4.5 MESSAGE_ID Object Usage ...................................12
4.6 MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage ....14
4.7 Multicast Considerations ..................................15
4.7.1 Reference RSVP/Routing Interface ..........................16
4.8 Compatibility .............................................16
5 Summary Refresh Extension .................................17
5.1 MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects ..........18
5.2 Srefresh Message Format ...................................24
5.3 Srefresh Message Usage ....................................25
5.4 Srefresh NACK .............................................28
5.5 Preserving RSVP Soft State ................................28
5.6 Compatibility .............................................29
6 Exponential Back-Off Procedures ...........................29
6.1 Outline of Operation ......................................30
6.2 Time Parameters ...........................................30
6.3 Retransmission Algorithm ..................................31
6.4 Performance Considerations ................................31
7 Acknowledgments ...........................................31
8 Security Considerations ...................................32
9 References ................................................32
10 Authors' Addresses ........................................33
11 Full Copyright Statement...................................34
1 Introduction and Background ................................2
1.1 Trigger and Refresh Messages ...............................4
2 Refresh-Reduction-Capable Bit ..............................4
3 RSVP Bundle Message ........................................5
3.1 Bundle Header ..............................................5
3.2 Message Formats ............................................6
3.3 Sending RSVP Bundle Messages ...............................7
3.4 Receiving RSVP Bundle Messages .............................8
4 MESSAGE_ID Extension .......................................8
4.1 Modification of Standard Message Formats ...................9
4.2 MESSAGE_ID Objects ........................................10
4.3 MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects ................11
4.4 Ack Message Format ........................................11
4.5 MESSAGE_ID Object Usage ...................................12
4.6 MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage ....14
4.7 Multicast Considerations ..................................15
4.7.1 Reference RSVP/Routing Interface ..........................16
4.8 Compatibility .............................................16
5 Summary Refresh Extension .................................17
5.1 MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects ..........18
5.2 Srefresh Message Format ...................................24
5.3 Srefresh Message Usage ....................................25
5.4 Srefresh NACK .............................................28
5.5 Preserving RSVP Soft State ................................28
5.6 Compatibility .............................................29
6 Exponential Back-Off Procedures ...........................29
6.1 Outline of Operation ......................................30
6.2 Time Parameters ...........................................30
6.3 Retransmission Algorithm ..................................31
6.4 Performance Considerations ................................31
7 Acknowledgments ...........................................31
8 Security Considerations ...................................32
9 References ................................................32
10 Authors' Addresses ........................................33
11 Full Copyright Statement...................................34
Standard RSVP [RFC2205] maintains state via the generation of RSVP refresh messages. Refresh messages are used to both synchronize state between RSVP neighbors and to recover from lost RSVP messages. The use of Refresh messages to cover many possible failures has resulted in a number of operational problems. One problem relates to scaling, another relates to the reliability and latency of RSVP Signaling.
标准RSVP[RFC2205]通过生成RSVP刷新消息来维护状态。刷新消息用于同步RSVP邻居之间的状态，以及从丢失的RSVP消息中恢复。使用刷新消息覆盖许多可能的故障导致了许多操作问题。一个问题与扩展有关，另一个问题与RSVP信令的可靠性和延迟有关。
The scaling problems are linked to the resource requirements (in terms of processing and memory) of running RSVP. The resource requirements increase proportionally with the number of sessions. Each session requires the generation, transmission, reception and processing of RSVP Path and Resv messages per refresh period. Supporting a large number of sessions, and the corresponding volume of refresh messages, presents a scaling problem.
扩展问题与运行RSVP的资源需求（在处理和内存方面）有关。所需资源随会议次数成比例增加。每个会话需要在每个刷新周期生成、传输、接收和处理RSVP Path和Resv消息。支持大量会话和相应数量的刷新消息会带来扩展问题。
The reliability and latency problem occurs when a non-refresh RSVP message is lost in transmission. Standard RSVP [RFC2205] recovers from a lost message via RSVP refresh messages. In the face of transmission loss of RSVP messages, the end-to-end latency of RSVP signaling is tied to the refresh interval of the node(s) experiencing the loss. When end-to-end signaling is limited by the refresh interval, the delay incurred in the establishment or the change of a reservation may be beyond the range of what is acceptable for some applications.
当非刷新RSVP消息在传输过程中丢失时，会出现可靠性和延迟问题。标准RSVP[RFC2205]通过RSVP刷新消息从丢失的消息中恢复。面对RSVP消息的传输丢失，RSVP信令的端到端延迟与经历丢失的节点的刷新间隔有关。当端到端信令受到刷新间隔的限制时，在保留的建立或更改中产生的延迟可能超出某些应用可接受的范围。
One way to address the refresh volume problem is to increase the refresh period, "R" as defined in Section 3.7 of [RFC2205]. Increasing the value of R provides linear improvement on transmission overhead, but at the cost of increasing the time it takes to synchronize state.
解决刷新量问题的一种方法是增加[RFC2205]第3.7节中定义的刷新周期“R”。增加R的值可以线性改善传输开销，但代价是增加同步状态所需的时间。
One way to address the reliability and latency of RSVP Signaling is to decrease the refresh period R. Decreasing the value of R increases the probability that state will be installed in the face of message loss, but at the cost of increasing refresh message rate and associated processing requirements.
解决RSVP信令的可靠性和延迟的一种方法是减少刷新周期R。减小R值会增加在消息丢失时安装状态的可能性，但代价是增加刷新消息速率和相关处理要求。
An additional issue is the time to deallocate resources after a tear message is lost. RSVP does not retransmit ResvTear or PathTear messages. If the sole tear message transmitted is lost, then resources will only be deallocated once the "cleanup timer" interval has passed. This may result in resources being allocated for an unnecessary period of time. Note that even when the refresh period is adjusted, the "cleanup timer" must still expire since tear messages are not retransmitted.
另一个问题是在删除消息丢失后释放资源的时间。RSVP不会重新传输ResvTear或PathTear消息。如果传输的唯一撕裂消息丢失，则只有在“清理计时器”间隔结束后，才会释放资源。这可能会导致资源被分配一段不必要的时间。请注意，即使调整了刷新周期，“清理计时器”也必须过期，因为撕裂消息不会重新传输。
The extensions defined in this document address both the refresh volume and the reliability issues with mechanisms other than adjusting refresh rate. The extensions are collectively referred to as the "Refresh Overhead Reduction" or the "Refresh Reduction" extensions. A Bundle message is defined to reduce overall message handling load. A MESSAGE_ID object is defined to reduce refresh message processing by allowing the receiver to more readily identify an unchanged message. A MESSAGE_ACK object is defined which can be used to detect message loss and support reliable RSVP message
本文档中定义的扩展通过调整刷新率以外的机制解决刷新量和可靠性问题。这些扩展统称为“刷新开销减少”或“刷新减少”扩展。定义捆绑消息以减少总体消息处理负载。消息ID对象被定义为通过允许接收方更容易地识别未更改的消息来减少刷新消息处理。定义了一个消息确认对象，该对象可用于检测消息丢失并支持可靠的RSVP消息
delivery on a per hop basis. A summary refresh message is defined to enable refreshing state without the transmission of whole refresh messages, while maintaining RSVP's ability to indicate when state is lost and to adjust to changes in routing.
以每跳为基础交付。摘要刷新消息定义为在不传输整个刷新消息的情况下启用刷新状态，同时保持RSVP指示状态何时丢失以及根据路由更改进行调整的能力。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document categorizes RSVP messages into two types: trigger and refresh messages. Trigger messages are those RSVP messages that advertise state or any other information not previously transmitted. Trigger messages include messages advertising new state, a route change that alters a reservation path, or a modification to an existing RSVP session or reservation. Trigger messages also include those messages that include changes in non-RSVP processed objects, such as changes in the Policy or ADSPEC objects.
本文档将RSVP消息分为两种类型：触发器消息和刷新消息。触发消息是那些通告状态或之前未传输的任何其他信息的RSVP消息。触发消息包括通告新状态的消息、更改保留路径的路由更改或对现有RSVP会话或保留的修改。触发器消息还包括那些包含非RSVP处理对象更改的消息，例如策略或ADSPEC对象中的更改。
Refresh messages represent previously advertised state and contain exactly the same objects and same information as a previously transmitted message, and are sent over the same path. Only Path and Resv messages can be refresh messages. Refresh messages are identical to the corresponding previously transmitted message, with some possible exceptions. Specifically, the checksum field, the flags field and the INTEGRITY object may differ in refresh messages.
刷新消息表示以前公布的状态，包含与以前传输的消息完全相同的对象和信息，并通过相同的路径发送。只有Path和Resv消息可以是刷新消息。刷新消息与先前传输的相应消息相同，但有一些可能的例外情况。具体而言，校验和字段、标志字段和完整性对象在刷新消息方面可能有所不同。
To indicate support for the refresh overhead reduction extensions, an additional capability bit is added to the common RSVP header, which is defined in [RFC2205].
为了表示对刷新开销减少扩展的支持，在[RFC2205]中定义的公共RSVP头中添加了一个额外的功能位。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | Msg Type | RSVP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | (Reserved) | RSVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | Msg Type | RSVP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | (Reserved) | RSVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 4 bits
标志：4位
0x01: Refresh (overhead) reduction capable
0x01:支持刷新（开销）减少
When set, indicates that this node is willing and capable of receiving all the messages and objects described in this document. This includes the Bundle message described in Section 3, the MESSAGE_ID objects and Ack messages described in Section 4, and the MESSAGE_ID LIST objects and Srefresh message described in Section 5. This bit is meaningful only between RSVP neighbors.
设置后，表示此节点愿意并能够接收本文档中描述的所有消息和对象。这包括第3节中描述的Bundle消息、第4节中描述的message_ID对象和Ack消息，以及第5节中描述的message_ID LIST对象和Srefresh消息。此位仅在RSVP邻居之间有意义。
Nodes supporting the refresh overhead reduction extensions must also take care to recognize when a next hop stops sending RSVP messages with the Refresh-Reduction-Capable bit set. To cover this case, nodes supporting the refresh overhead reduction extensions MUST examine the flags field of each received RSVP message. If the flag changes from indicating support to indicating non-support then, unless configured otherwise, Srefresh messages (described in Section 5) MUST NOT be used for subsequent state refreshes to that neighbor and Bundle messages (Section 3) MUST NOT be sent to that neighbor. Note, a node that supports reliable RSVP message delivery (Section 4) but not Bundle and Srefresh messages, will not set the Refresh-Reduction-Capable bit.
支持刷新开销减少扩展的节点还必须注意识别下一跳何时停止发送具有刷新开销减少功能的位集的RSVP消息。为了解决这种情况，支持刷新开销减少扩展的节点必须检查每个接收到的RSVP消息的标志字段。如果标志从表示支持变为表示不支持，则除非另有配置，否则Srefresh消息（第5节中描述）不得用于后续状态刷新到该邻居，捆绑消息（第3节）不得发送到该邻居。注意，支持可靠RSVP消息传递（第4节）但不支持捆绑和Srefresh消息的节点将不会设置可刷新减少的位。
An RSVP Bundle message consists of a bundle header followed by a body consisting of a variable number of standard RSVP messages. A Bundle message is used to aggregate multiple RSVP messages within a single PDU. The term "bundling" is used to avoid confusion with RSVP reservation aggregation. The following subsections define the formats of the bundle header and the rules for including standard RSVP messages as part of the message.
RSVP捆绑消息由捆绑头和正文组成，正文由数量可变的标准RSVP消息组成。捆绑消息用于在单个PDU内聚合多个RSVP消息。术语“捆绑”用于避免与RSVP保留聚合混淆。以下小节定义了捆绑头的格式以及将标准RSVP消息作为消息一部分的规则。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | Msg type | RSVP checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | (Reserved) | RSVP length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | Msg type | RSVP checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | (Reserved) | RSVP length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the bundle header is identical to the format of the RSVP common header [RFC2205]. The fields in the header are as follows:
捆绑头的格式与RSVP公共头的格式相同[RFC2205]。标题中的字段如下所示：
Vers: 4 bits
版本：4位
Protocol version number. This is version 1.
协议版本号。这是第1版。
Flags: 4 bits
标志：4位
0x01: Refresh (overhead) reduction capable
0x01:支持刷新（开销）减少
See Section 2.
见第2节。
0x02-0x08: Reserved
0x02-0x08：保留
Msg type: 8 bits
消息类型：8位
12 = Bundle
12 = Bundle
RSVP checksum: 16 bits
RSVP校验和：16位
The one's complement of the one's complement sum of the entire message, with the checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted. Because individual sub-messages may carry their own checksum as well as the INTEGRITY object for authentication, this field MAY be set to zero. Note that when the checksum is not computed, the header of the bundle message will not be covered by any checksum. If the checksum is computed, individual sub-messages MAY set their own checksum to zero.
整个消息的一个补码和的一个补码，为了计算校验和，校验和字段替换为零。全零值表示未传输校验和。由于单个子消息可能携带自己的校验和以及用于身份验证的完整性对象，因此此字段可能设置为零。请注意，当未计算校验和时，任何校验和都不会覆盖捆绑消息的头。如果计算了校验和，则各个子消息可以将其自身的校验和设置为零。
Send_TTL: 8 bits
发送\u TTL:8位
The IP TTL value with which the message was sent. This is used by RSVP to detect a non-RSVP hop by comparing the Send_TTL with the IP TTL in a received message.
发送消息时使用的IP TTL值。RSVP通过比较接收消息中的发送TTL和IP TTL来检测非RSVP跳。
RSVP length: 16 bits
RSVP长度：16位
The total length of this RSVP Bundle message in bytes, including the bundle header and the sub-messages that follow.
此RSVP捆绑消息的总长度（以字节为单位），包括捆绑头和随后的子消息。
An RSVP Bundle message must contain at least one sub-message. A sub-message MAY be any message type except for another Bundle message.
RSVP捆绑消息必须至少包含一个子消息。子消息可以是除另一个捆绑消息之外的任何消息类型。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | 12 | RSVP checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | (Reserved) | RSVP length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// First sub-message //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// More sub-messages.. //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | 12 | RSVP checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | (Reserved) | RSVP length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// First sub-message //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// More sub-messages.. //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Support for RSVP Bundle messages is optional. While message bundling helps in scaling RSVP, by reducing processing overhead and bandwidth consumption, a node is not required to transmit every standard RSVP message in a Bundle message. A node MUST always be ready to receive standard RSVP messages.
对RSVP捆绑消息的支持是可选的。虽然消息绑定有助于扩展RSVP，但通过减少处理开销和带宽消耗，节点不需要传输捆绑消息中的每个标准RSVP消息。节点必须始终准备好接收标准RSVP消息。
RSVP Bundle messages can only be sent to RSVP neighbors that support bundling. Methods for discovering such information include: (1) manual configuration and (2) observing the Refresh-Reduction-Capable bit (see Section 2) in the received RSVP messages. RSVP Bundle messages MUST NOT be used if the RSVP neighbor does not support RSVP Bundle messages.
RSVP捆绑消息只能发送给支持捆绑的RSVP邻居。发现此类信息的方法包括：（1）手动配置和（2）观察接收到的RSVP消息中的可刷新减少位（见第2节）。如果RSVP邻居不支持RSVP捆绑消息，则不得使用RSVP捆绑消息。
RSVP Bundle messages are sent hop by hop between RSVP-capable nodes as "raw" IP datagrams with protocol number 46. The IP source address is an address local to the system that originated the Bundle message. The IP destination address is the RSVP neighbor for which the sub-messages are intended.
RSVP捆绑消息在支持RSVP的节点之间逐跳发送，作为协议号为46的“原始”IP数据报。IP源地址是发起捆绑消息的系统的本地地址。IP目标地址是子消息的目标RSVP邻居。
RSVP Bundle messages SHOULD NOT be sent with the Router Alert IP option in their IP headers. This is because Bundle messages are addressed directly to RSVP neighbors.
RSVP捆绑消息不应在其IP头中使用路由器警报IP选项发送。这是因为捆绑消息直接发送给RSVP邻居。
Each RSVP Bundle message MUST occupy exactly one IP datagram, which is approximately 64K bytes. If it exceeds the MTU, the datagram is fragmented by IP and reassembled at the recipient node. Implementations may choose to limit each RSVP Bundle message to the MTU size of the outgoing link, e.g., 1500 bytes. Implementations SHOULD also limit the amount of time that a message is delayed in order to be bundled. Different limits may be used for trigger and
每个RSVP包消息必须恰好占用一个IP数据报，约为64K字节。如果超过MTU，数据报将被IP分段并在接收方节点重新组装。实现可以选择将每个RSVP包消息限制为传出链路的MTU大小，例如1500字节。实现还应该限制消息延迟的时间量，以便进行绑定。触发器和控制器可使用不同的限值
standard refresh messages. Trigger messages SHOULD be delayed a minimal amount of time. Refresh messages may be delayed up to their refresh interval. Note that messages related to the same Resv or Path state should not be delayed at different intervals in order to preserve ordering.
标准刷新消息。触发消息应延迟最短时间。刷新消息可能会延迟到其刷新间隔。请注意，与同一Resv或路径状态相关的消息不应以不同的时间间隔延迟，以保持顺序。
If the RSVP neighbor is not known or changes in next hops cannot be identified via routing, Bundle messages MUST NOT be used. Note that when the routing next hop is not RSVP capable it will typically not be possible to identify changes in next hop.
如果RSVP邻居未知或无法通过路由识别下一个跃点中的更改，则不得使用捆绑消息。请注意，当路由下一跳不支持RSVP时，通常无法识别下一跳中的更改。
Any message that will be handled by the RSVP neighbor indicated in a Bundle Message's destination address may be included in the same message. This includes all RSVP messages that would be sent out a point-to-point link. It includes any message, such as a Resv, addressed to the same destination address. It also includes Path and PathTear messages when the next hop is known to be the destination and changes in next hops can be detected. Path and PathTear messages for multicast sessions MUST NOT be sent in Bundle messages when the outgoing link is not a point-to-point link or when the next hop does not support the refresh overhead reduction extensions.
捆绑消息的目标地址中指示的RSVP邻居将处理的任何消息都可以包含在同一消息中。这包括将通过点对点链接发送的所有RSVP消息。它包括发往同一目标地址的任何消息，如Resv。当知道下一个跃点是目标并且可以检测到下一个跃点中的更改时，它还包括Path和PATHTRAL消息。当传出链路不是点到点链路或下一跳不支持刷新开销减少扩展时，多播会话的Path和PATHTRAL消息不得以捆绑消息的形式发送。
If the local system does not recognize or does not wish to accept a Bundle message, the received messages shall be discarded without further analysis.
如果本地系统不识别或不希望接受捆绑消息，则应丢弃接收到的消息，无需进一步分析。
The receiver next compares the Send_TTL with which a Bundle message is sent to the IP TTL with which it is received. If a non-RSVP hop is detected, the number of non-RSVP hops is recorded. It is used later in processing of sub-messages.
然后，接收器将发送捆绑消息的发送TTL与接收捆绑消息的IP TTL进行比较。如果检测到非RSVP跳，则记录非RSVP跳数。它稍后用于处理子消息。
Next, the receiver verifies the version number and checksum of the RSVP Bundle message and discards the message if any mismatch is found.
接下来，接收方验证RSVP捆绑消息的版本号和校验和，如果发现任何不匹配，则丢弃该消息。
The receiver then starts decapsulating individual sub-messages. Each sub-message has its own complete message length and authentication information. With the exception of using the Send_TTL from the header of the Bundle message, each sub-message is processed as if it was received individually.
然后，接收器开始解封各个子消息。每个子消息都有自己完整的消息长度和身份验证信息。除了使用来自捆绑消息头的Send_TTL外，每个子消息的处理都如同单独接收一样。
Three new objects are defined as part of the MESSAGE_ID extension. The objects are the MESSAGE_ID object, the MESSAGE_ID_ACK object, and the MESSAGE_ID_NACK objects. The first two objects are used to
三个新对象被定义为MESSAGE_ID扩展的一部分。这些对象是MESSAGE_ID对象、MESSAGE_ID_ACK对象和MESSAGE_ID_NACK对象。前两个对象用于
support acknowledgments and reliable RSVP message delivery. The last object is used to support the summary refresh extension described in Section 5. The MESSAGE_ID object can also be used to simply provide a shorthand indication of when the message carrying the object is a refresh message. Such information can be used by the receiving node to reduce refresh processing requirements.
支持确认和可靠的RSVP消息传递。最后一个对象用于支持第5节中描述的摘要刷新扩展。MESSAGE_ID对象还可以用于简单地提供一个速记指示，指示携带该对象的消息何时是刷新消息。接收节点可以使用这些信息来减少刷新处理需求。
Message identification and acknowledgment is done on a per hop basis. All types of MESSAGE_ID objects contain a message identifier. The identifier MUST be unique on a per object generator's IP address basis. No more than one MESSAGE_ID object may be included in an RSVP message. Each message containing a MESSAGE_ID object may be acknowledged via a MESSAGE_ID_ACK object, when so indicated. MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be sent piggy-backed in unrelated RSVP messages or in RSVP Ack messages. RSVP messages carrying any of the three object types may be included in a bundle message. When included, each object is treated as if it were contained in a standard, non-bundled, RSVP message.
消息识别和确认是在每跳的基础上完成的。所有类型的消息ID对象都包含消息标识符。标识符在每个对象生成器的IP地址上必须是唯一的。RSVP消息中只能包含一个消息\u ID对象。当指示时，包含消息标识对象的每条消息可通过消息标识确认对象进行确认。MESSAGE_ID_ACK和MESSAGE_ID_NACK对象可以在不相关的RSVP消息或RSVP ACK消息中发送。携带三种对象类型中任何一种的RSVP消息可以包含在捆绑消息中。包含时，每个对象都被视为包含在标准、非绑定的RSVP消息中。
The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be included in the standard RSVP messages, as defined in [RFC2205]. When included, one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK objects MUST immediately follow the INTEGRITY object. When no INTEGRITY object is present, the MESSAGE_ID_ACK or MESSAGE_ID_NACK objects MUST immediately follow the message or sub-message header. Only one MESSAGE_ID object MAY be included in a message or sub-message and it MUST follow any present MESSAGE_ID_ACK or MESSAGE_ID_NACK objects. When no MESSAGE_ID_ACK or MESSAGE_ID_NACK objects are present, the MESSAGE_ID object MUST immediately follow the INTEGRITY object. When no INTEGRITY object is present, the MESSAGE_ID object MUST immediately follow the message or sub-message header.
消息标识、消息标识确认和消息标识NACK对象可包括在标准RSVP消息中，如[RFC2205]中所定义。包含时，一个或多个MESSAGE_ID_ACK或MESSAGE_ID_NACK对象必须紧跟在INTEGRITY对象之后。当不存在完整性对象时，消息\u ID\u ACK或消息\u ID\u NACK对象必须紧跟在消息或子消息头之后。一条消息或子消息中只能包含一个消息ID对象，它必须位于任何当前消息ID ACK或消息ID NACK对象之后。当不存在MESSAGE_ID_ACK或MESSAGE_ID_NACK对象时，MESSAGE_ID对象必须紧跟在INTEGRITY对象之后。当不存在完整性对象时，消息\u ID对象必须紧跟在消息或子消息头之后。
The ordering of the ACK objects for all standard RSVP messages is:
<Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
The ordering of the ACK objects for all standard RSVP messages is:
<Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
MESSAGE_ID Class = 23
消息\u ID Class=23
MESSAGE_ID object
消息ID对象
Class = MESSAGE_ID Class, C_Type = 1
类=消息ID类，C\U类型=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits
标志：8位
0x01 = ACK_Desired flag
0x01 = ACK_Desired flag
Indicates that the sender requests the receiver to send an acknowledgment for the message.
指示发送方请求接收方发送消息确认。
Epoch: 24 bits
纪元：24位
A value that indicates when the Message_Identifier sequence has reset. SHOULD be randomly generated each time a node reboots or the RSVP agent is restarted. The value SHOULD NOT be the same as was used when the node was last operational. This value MUST NOT be changed during normal operation.
指示消息_标识符序列何时重置的值。应在每次节点重新启动或RSVP代理重新启动时随机生成。该值不应与节点上次运行时使用的值相同。正常操作期间不得更改此值。
Message_Identifier: 32 bits
消息标识符：32位
When combined with the message generator's IP address, the Message_Identifier field uniquely identifies a message. The values placed in this field change incrementally and only decrease when the Epoch changes or when the value wraps.
当与消息生成器的IP地址组合时，消息标识符字段唯一标识消息。放置在该字段中的值以增量方式更改，并且仅在历元更改或值换行时减少。
MESSAGE_ID_ACK Class = 24
消息ID确认类=24
MESSAGE_ID_ACK object
消息\u ID\u确认对象
Class = MESSAGE_ID_ACK Class, C_Type = 1
类=消息\u ID\u确认类，C\u类型=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits
标志：8位
No flags are currently defined. This field MUST be zero on transmission and ignored on receipt.
当前未定义任何标志。此字段在传输时必须为零，在接收时必须忽略。
Epoch: 24 bits
纪元：24位
The Epoch field copied from the message being acknowledged.
从正在确认的消息复制的历元字段。
Message_Identifier: 32 bits
消息标识符：32位
The Message_Identifier field copied from the message being acknowledged.
从正在确认的消息复制的消息标识符字段。
MESSAGE_ID_NACK object
消息\u ID\u NACK对象
Class = MESSAGE_ID_ACK Class, C_Type = 2
类=消息\u ID\u确认类，C\u类型=2
Definition is the same as the MESSAGE_ID_ACK object.
定义与消息\u ID\u ACK对象相同。
Ack messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK objects. They MUST NOT contain any MESSAGE_ID objects. Ack messages are sent between neighboring RSVP nodes. The IP destination address of an Ack message is the unicast address of the node that generated the message(s) being acknowledged. For messages with RSVP_HOP objects, such as Path and Resv messages, the address is found in the RSVP_HOP object. For other messages, such as ResvConf, the associated IP address is the source address in the IP header. The IP source address is an address of the node that sends the Ack message.
确认消息携带一个或多个消息ID确认或消息ID NACK对象。它们不能包含任何消息ID对象。Ack消息在相邻RSVP节点之间发送。Ack消息的IP目标地址是生成被确认消息的节点的单播地址。对于带有RSVP_-HOP对象的消息，例如Path和Resv消息，地址位于RSVP_-HOP对象中。对于其他消息，如ResvConf，关联的IP地址是IP头中的源地址。IP源地址是发送Ack消息的节点的地址。
The Ack message format is as follows:
Ack消息格式如下所示：
<ACK Message> ::= <Common Header> [ <INTEGRITY> ]
<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
<ACK Message> ::= <Common Header> [ <INTEGRITY> ]
<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
For Ack messages, the Msg Type field of the Common Header MUST be set to 13.
对于Ack消息，公共标头的Msg Type字段必须设置为13。
Section 4.6 provides guidance on when an Ack message should be used and when MESSAGE_ID objects should be sent piggy-backed in other RSVP messages.
第4.6节提供了关于何时应使用Ack消息以及何时应在其他RSVP消息中发送消息ID对象的指南。
The MESSAGE_ID object may be included in any RSVP message other than the Ack and Bundle messages. The MESSAGE_ID object is always generated and processed over a single hop between RSVP neighbors. The IP address of the object generator, i.e., the node that creates the object, is represented in a per RSVP message type specific fashion. For messages with RSVP_HOP objects, such as Path and Resv messages, the generator's IP address is found in the RSVP_HOP object. For other messages, such as ResvConf message, the generator's IP address is the source address in the IP header. Note that MESSAGE_ID objects can only be used in a Bundle sub-messages, but not in a Bundle message. As is always the case with the Bundle message, each sub-message is processed as if it was received individually. This includes processing of MESSAGE_ID objects.
除Ack和Bundle消息外，MESSAGE_ID对象可以包含在任何RSVP消息中。消息_ID对象始终在RSVP邻居之间的单跳上生成和处理。对象生成器的IP地址，即创建对象的节点，以每个RSVP消息类型特定的方式表示。对于带有RSVP_-HOP对象的消息，例如Path和Resv消息，可以在RSVP_-HOP对象中找到生成器的IP地址。对于其他消息，例如ResvConf消息，生成器的IP地址是IP头中的源地址。请注意，MESSAGE_ID对象只能在捆绑子消息中使用，而不能在捆绑消息中使用。与Bundle消息的情况一样，每个子消息的处理方式都如同单独接收一样。这包括消息ID对象的处理。
The Epoch field contains a generator selected value. The value is used to indicate when the sender resets the values used in the Message_Identifier field. On startup, a node SHOULD randomly select a value to be used in the Epoch field. The node SHOULD ensure that the selected value is not the same as was used when the node was last operational. The value MUST NOT be changed unless the node or the RSVP agent is restarted.
“历元”字段包含生成器选择的值。该值用于指示发送方何时重置消息标识符字段中使用的值。启动时，节点应随机选择要在“历元”字段中使用的值。节点应确保所选值与节点上次运行时使用的值不同。除非重新启动节点或RSVP代理，否则不得更改该值。
The Message_Identifier field contains a generator selected value. This value, when combined with the generator's IP address, identifies a particular RSVP message and the specific state information it represents. The combination of Message_Identifier and Epoch can also be used to detect out of order messages. When a node is sending a refresh message with a MESSAGE_ID object, it SHOULD use the same Message_Identifier value that was used in the RSVP message that first advertised the state being refreshed. When a node is sending a trigger message, the Message_Identifier value MUST have a value that is greater than any other value previously used with the same Epoch field value. A value is considered to have been used when it has
消息标识符字段包含生成器选择的值。该值与生成器的IP地址结合使用时，标识特定的RSVP消息及其表示的特定状态信息。消息标识符和历元的组合也可用于检测无序消息。当节点发送带有message_ID对象的刷新消息时，它应该使用与第一次公布刷新状态的RSVP消息中使用的相同message_标识符值。当节点发送触发消息时，消息_标识符值的值必须大于先前使用相同历元字段值的任何其他值。如果某个值已被使用，则认为该值已被使用
been sent in any message using the associated IP address with the same Epoch field value.
已使用具有相同历元字段值的关联IP地址在任何消息中发送。
The ACK_Desired flag is set when the MESSAGE_ID object generator wants a MESSAGE_ID_ACK object sent in response to the message. Such information can be used to ensure reliable delivery of RSVP messages in the face of network loss. Nodes setting the ACK_Desired flag SHOULD retransmit unacknowledged messages at a more rapid interval than the standard refresh period until the message is acknowledged or until a "rapid" retry limit is reached. Rapid retransmission rate MUST be based on the exponential exponential back-off procedures defined in section 6. The ACK_Desired flag will typically be set only in trigger messages. The ACK_Desired flag MAY be set in refresh messages. Issues relate to multicast sessions are covered in a later section.
当消息\u ID对象生成器希望发送消息\u ID\u ACK对象以响应消息时，将设置ACK\u Desired标志。此类信息可用于在网络丢失时确保RSVP消息的可靠传递。设置ACK_所需标志的节点应以比标准刷新周期更快的间隔重新传输未确认的消息，直到消息被确认或达到“快速”重试限制。快速重传率必须基于第6节中定义的指数退避程序。ACK_所需标志通常仅在触发消息中设置。可在刷新消息中设置ACK_所需标志。与多播会话相关的问题将在后面的部分中介绍。
Nodes processing incoming MESSAGE_ID objects SHOULD check to see if a newly received message is out of order and can be ignored. Out of order messages SHOULD be ignored, i.e., silently dropped. Out of order messages can be identified by examining the values in the Epoch and Message_Identifier fields. To determine ordering, the received Epoch value must match the value previously received from the message sender. If the values differ then the receiver MUST NOT treat the message as out of order. When the Epoch values match and the Message_Identifier value is less than the largest value previously received from the sender, then the receiver SHOULD check the value previously received for the state associated with the message. This check should be performed for any message that installs or changes state. (Includes at least: Path, Resv, PathTear, ResvTear, PathErr and ResvErr.) If no local state information can be associated with the message, the receiver MUST NOT treat the message as out of order. If local state can be associated with the message and the received Message_Identifier value is less than the most recently received value associated with the state, the message SHOULD be treated as being out of order.
处理传入消息\u ID对象的节点应检查新接收的消息是否有问题，是否可以忽略。应忽略顺序错误的消息，即，悄悄删除。可以通过检查历元和消息标识符字段中的值来识别无序消息。要确定顺序，收到的历元值必须与以前从消息发送方收到的值相匹配。如果值不同，则接收者不得将消息视为无序。当历元值匹配且消息_标识符值小于先前从发送方收到的最大值时，接收方应检查先前收到的值，以了解与消息相关的状态。应该对安装或更改状态的任何邮件执行此检查。（至少包括：Path、Resv、pathtreal、ResvTear、PathErr和ResvErr。）如果没有本地状态信息可以与消息关联，则接收方不得将消息视为无序。如果本地状态可与消息关联，且收到的消息_标识符值小于与状态关联的最近收到的值，则应将消息视为无序。
Note that the 32-bit Message_Identifier value MAY wrap. To cover the wrap case, the following expression may be used to test if a newly received Message_Identifier value is less than a previously received value:
请注意，32位消息_标识符值可能会换行。为了涵盖包装情况，可使用以下表达式测试新接收的消息_标识符值是否小于先前接收的值：
if ((int) old_id - (int) new_id > 0) {
new value is less than old value;
}
if ((int) old_id - (int) new_id > 0) {
new value is less than old value;
}
MESSAGE_ID objects of messages that are not out of order SHOULD be used to aid in determining if the message represents new state or a state refresh. Note that state is only refreshed in Path and Resv
应使用未无序的消息的消息ID对象来帮助确定消息是表示新状态还是状态刷新。请注意，状态仅在Path和Resv中刷新
messages. If the received Epoch values differs from the value previously received from the message sender, the message is a trigger message and the receiver MUST fully process the message. If a Path or Resv message contains the same Message_Identifier value that was used in the most recently received message for the same session and, for Path messages, SENDER_TEMPLATE then the receiver SHOULD treat the message as a state refresh. If the Message_Identifier value is greater than the most recently received value, the receiver MUST fully processes the message. When fully processing a Path or Resv message, the receiver MUST store the received Message_Identifier value as part of the local Path or Resv state for future reference.
信息。如果接收到的历元值与先前从消息发送方接收到的值不同，则该消息为触发消息，接收方必须完全处理该消息。如果Path或Resv消息包含在同一会话的最近接收消息中使用的相同消息标识符值，并且对于Path消息，包含发送方模板，则接收方应将该消息视为状态刷新。如果消息_标识符值大于最近接收的值，则接收方必须完全处理该消息。当完全处理路径或Resv消息时，接收方必须将接收到的消息_标识符值存储为本地路径或Resv状态的一部分，以供将来参考。
Nodes receiving a non-out of order message containing a MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with a MESSAGE_ID_ACK object. Note that MESSAGE_ID objects received in messages containing errors, i.e., are not syntactically valid, MUST NOT be acknowledged. PathErr and ResvErr messages SHOULD be treated as implicit acknowledgments.
接收包含设置了ACK\U所需标志的message\U ID对象的非故障消息的节点应使用message\U ID\U ACK对象进行响应。请注意，在包含错误的消息中接收的MESSAGE_ID对象（即语法无效）不能被确认。PathErr和ResvErr消息应视为隐式确认。
The MESSAGE_ID_ACK object is used to acknowledge receipt of messages containing MESSAGE_ID objects that were sent with the ACK_Desired flag set. A MESSAGE_ID_ACK object MUST NOT be generated in response to a received MESSAGE_ID object when the ACK_Desired flag is not set.
MESSAGE_ID_ACK对象用于确认收到包含MESSAGE_ID对象的消息，这些对象是使用ACK_Desired标志集发送的。未设置ACK\U REQUIRED标志时，不得生成消息\U ID\U ACK对象以响应接收到的消息\U ID对象。
The MESSAGE_ID_NACK object is used as part of the summary refresh extension. The generation and processing of MESSAGE_ID_NACK objects is described in further detail in Section 5.4.
消息_ID_NACK对象用作摘要刷新扩展的一部分。第5.4节进一步详细描述了消息_ID_NACK对象的生成和处理。
MESSAGE_ID_ACK and MESSAGE_ID_NACK objects MAY be sent in any RSVP message that has an IP destination address matching the generator of the associated MESSAGE_ID object. This means that the objects will not typically be included in the non hop-by-hop Path, PathTear and ResvConf messages. When no appropriate message is available, one or more objects SHOULD be sent in an Ack message. Implementations SHOULD include MESSAGE_ID_ACK and MESSAGE_ID_NACK objects in standard RSVP messages when possible.
MESSAGE_ID_ACK和MESSAGE_ID_NACK对象可以在任何RSVP消息中发送，该RSVP消息具有与关联MESSAGE_ID对象的生成器匹配的IP目的地地址。这意味着这些对象通常不会包含在非逐跳路径、PathTear和ResvConf消息中。当没有合适的消息可用时，应在Ack消息中发送一个或多个对象。在可能的情况下，实现应在标准RSVP消息中包括消息ID ACK和消息ID NACK对象。
Implementations SHOULD limit the amount of time that an object is delayed in order to be piggy-backed or sent in an Ack message. Different limits may be used for MESSAGE_ID_ACK and MESSAGE_ID_NACK objects. MESSAGE_ID_ACK objects are used to detect link transmission losses. If an ACK object is delayed too long, the corresponding message will be retransmitted. To avoid such retransmission, ACK objects SHOULD be delayed a minimal amount of time. A delay time equal to the link transit time MAY be used. MESSAGE_ID_NACK objects may be delayed an independent and longer time, although additional
实现应该限制对象延迟的时间量，以便在Ack消息中进行背载或发送。消息标识确认和消息标识确认对象可以使用不同的限制。MESSAGE_ID_ACK对象用于检测链路传输损耗。如果ACK对象延迟过长，则将重新传输相应的消息。为了避免这种重传，ACK对象应该延迟最少的时间。可以使用等于链路传输时间的延迟时间。消息\u ID\u NACK对象可能会被延迟一段独立的较长时间，尽管有额外的延迟
delay increases the amount of time a desired reservation is not installed.
延迟会增加未安装所需预订的时间。
Path and PathTear messages may be sent to IP multicast destination addresses. When the destination is a multicast address, it is possible that a single message containing a single MESSAGE_ID object will be received by multiple RSVP next hops. When the ACK_Desired flag is set in this case, acknowledgment processing is more complex.
路径和路径撕裂消息可以发送到IP多播目标地址。当目的地是多播地址时，多个RSVP下一跳可能会接收到包含单个消息ID对象的单个消息。在这种情况下，当设置ACK_所需标志时，确认处理更为复杂。
There are a number of issues to be addressed including ACK implosion, number of acknowledgments to be expected and handling of new receivers.
有许多问题需要解决，包括ACK内爆、预期的确认数量和新接收器的处理。
ACK implosion occurs when each receiver responds to the MESSAGE_ID object at approximately the same time. This can lead to a potentially large number of MESSAGE_ID_ACK objects being simultaneously delivered to the message generator. To address this case, the receiver MUST wait a random interval prior to acknowledging a MESSAGE_ID object received in a message destined to a multicast address. The random interval SHOULD be between zero (0) and a configured maximum time. The configured maximum SHOULD be set in proportion to the refresh and "rapid" retransmission interval, i.e, such that the maximum time before sending an acknowledgment does not result in retransmission. It should be noted that ACK implosion is being addressed by spreading acknowledgments out in time, not by ACK suppression.
当每个接收器几乎同时响应消息_ID对象时，ACK内爆发生。这可能会导致大量的MESSAGE_ID_ACK对象同时传递到MESSAGE generator。为了解决这种情况，接收器必须在确认在发送到多播地址的消息中接收到的消息\u ID对象之前等待随机间隔。随机间隔应介于零（0）和配置的最长时间之间。配置的最大值应与刷新和“快速”重传间隔成比例设置，即，发送确认之前的最大时间不会导致重传。应该注意的是，ACK内爆是通过及时传播确认来解决的，而不是通过ACK抑制来解决的。
A more fundamental issue is the number of acknowledgments that the upstream node, i.e., the message generator, should expect. The number of acknowledgments that should be expected is the same as the number of RSVP next hops. In the router-to-router case, the number of next hops can often be obtained from routing. When hosts are either the upstream node or the next hops, the number of next hops will typically not be readily available. Another case where the number of RSVP next hops will typically not be known is when there are non-RSVP routers between the message generator and the RSVP next hops.
更基本的问题是上游节点（即消息生成器）应该期望的确认数量。应预期的确认数与RSVP下一跳数相同。在路由器到路由器的情况下，下一跳的数量通常可以通过路由获得。当主机是上游节点或下一跳时，下一跳的数量通常不可用。通常不知道RSVP下一跳数的另一种情况是，在消息生成器和RSVP下一跳之间存在非RSVP路由器。
When the number of next hops is not known, the message generator SHOULD only expect a single response. The result of this behavior will be special retransmission handling until the message is delivered to at least one next hop, then followed by standard RSVP refreshes. Refresh messages will synchronize state with any next hops that don't receive the original message.
如果不知道下一个跃点的数量，则消息生成器应该只期望一个响应。这种行为的结果将是特殊的重传处理，直到消息被传递到至少一个下一跳，然后是标准的RSVP刷新。刷新消息将使状态与未接收原始消息的任何下一个跃点同步。
When using the MESSAGE_ID extension with multicast sessions it is preferable for RSVP to obtain the number of next hops from routing and to be notified when that number changes. The interface between routing and RSVP is purely an implementation issue. Since RSVP [RFC2205] describes a reference routing interface, a version of the RSVP/routing interface updated to provide number of next hop information is presented. See [RFC2205] for previously defined parameters and function description.
当在多播会话中使用消息\u ID扩展时，RSVP最好从路由中获取下一个跃点的数量，并在该数量发生变化时得到通知。路由和RSVP之间的接口纯粹是一个实现问题。由于RSVP[RFC2205]描述了一个参考路由接口，因此提供了一个版本的RSVP/路由接口，该接口更新后可提供下一跳的数量信息。有关先前定义的参数和功能说明，请参见[RFC2205]。
o Route Query Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag ) -> [ IncInterface, ] OutInterface_list, NHops_list
o 路由查询Mcast\u路由查询（[SrcAddress，]DestAddress，Notify\u标志）->[IncInterface，]OutInterface\u列表，NHops\u列表
o Route Change Notification Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, [ IncInterface, ] OutInterface_list, NHops_list
o 路由更改通知Mcast\u路由更改（）->[SrcAddress，]DestAddress，[IncInterface，]OutInterface\u列表，NHops\u列表
NHops_list provides the number of multicast group members reachable via each OutInterface_list entry.
NHops_列表提供可通过每个OutInterface_列表项访问的多播组成员数。
All nodes sending messages with the Refresh-Reduction-Capable bit set will support the MESSAGE_ID Extension. There are no backward compatibility issues raised by the MESSAGE_ID Class with nodes that do not set the Refresh-Reduction-Capable bit. The MESSAGE_ID Class has an assigned value whose form is 0bbbbbbb. Per RSVP [RFC2205], classes with values of this form must be rejected with an "Unknown Object Class" error by nodes not supporting the class. When the receiver of a MESSAGE_ID object does not support the class, a corresponding error message will be generated. The generator of the MESSAGE_ID object will see the error and then MUST re-send the original message without the MESSAGE_ID object. In this case, the message generator MAY still choose to retransmit messages at the "rapid" retransmission interval. Lastly, since the MESSAGE_ID_ACK class can only be issued in response to the MESSAGE_ID object, there are no possible issues with this class or Ack messages. A node MAY support the MESSAGE_ID Extension without supporting the other refresh overhead reduction extensions.
发送具有刷新减少功能位集的消息的所有节点都将支持消息\u ID扩展。MESSAGE_ID类与未设置刷新减少功能位的节点之间不存在向后兼容性问题。MESSAGE_ID类具有一个形式为0bbb的赋值。根据RSVP[RFC2205]，具有此形式值的类必须被不支持该类的节点以“未知对象类”错误拒绝。当MESSAGE_ID对象的接收者不支持该类时，将生成相应的错误消息。MESSAGE_ID对象的生成器将看到错误，然后必须在没有MESSAGE_ID对象的情况下重新发送原始消息。在这种情况下，消息生成器仍然可以选择以“快速”重传间隔重传消息。最后，由于MESSAGE_ID_ACK类只能响应MESSAGE_ID对象而发出，因此此类或ACK消息不存在可能的问题。节点可以支持消息ID扩展，而不支持其他刷新开销减少扩展。
The summary refresh extension enables the refreshing of RSVP state without the transmission of standard Path or Resv messages. The benefits of the described extension are that it reduces the amount of information that must be transmitted and processed in order to maintain RSVP state synchronization. Importantly, the described extension preserves RSVP's ability to handle non-RSVP next hops and to adjust to changes in routing. This extension cannot be used with Path or Resv messages that contain any change from previously transmitted messages, i.e., are trigger messages.
摘要刷新扩展支持在不传输标准路径或Resv消息的情况下刷新RSVP状态。所述扩展的好处在于，它减少了为了保持RSVP状态同步而必须传输和处理的信息量。重要的是，所描述的扩展保留了RSVP处理非RSVP下一跳和调整路由变化的能力。此扩展不能用于包含先前传输消息的任何更改的Path或Resv消息，即触发消息。
The summary refresh extension builds on the previously defined MESSAGE_ID extension. Only state that was previously advertised in Path and Resv messages containing MESSAGE_ID objects can be refreshed via the summary refresh extension.
摘要刷新扩展以先前定义的消息\u ID扩展为基础。只有先前在包含消息ID对象的Path和Resv消息中播发的状态才能通过摘要刷新扩展进行刷新。
The summary refresh extension uses the objects and the ACK message previously defined as part of the MESSAGE_ID extension, and a new Srefresh message. The new message carries a list of Message_Identifier fields corresponding to the Path and Resv trigger messages that established the state. The Message_Identifier fields are carried in one of three Srefresh related objects. The three objects are the MESSAGE_ID LIST object, the MESSAGE_ID SRC_LIST object, and the MESSAGE_ID MCAST_LIST object.
摘要刷新扩展使用以前定义为消息\u ID扩展的一部分的对象和确认消息，以及新的Srefresh消息。新消息包含与建立状态的路径和Resv触发器消息相对应的消息标识符字段列表。消息_标识符字段包含在三个Srefresh相关对象之一中。这三个对象是MESSAGE\u ID LIST对象、MESSAGE\u ID SRC\u LIST对象和MESSAGE\u ID MCAST\u LIST对象。
The MESSAGE_ID LIST object is used to refresh all Resv state, and Path state of unicast sessions. It is made up of a list of Message_Identifier fields that were originally advertised in MESSAGE_ID objects. The other two objects are used to refresh Path state of multicast sessions. A node receiving a summary refresh for multicast path state will at times need source and group information. These two objects provide this information. The objects differ in the information they contain and how they are sent. Both carry Message_Identifier fields and corresponding source IP addresses. The MESSAGE_ID SRC_LIST is sent in messages addressed to the session's multicast IP address. The MESSAGE_ID MCAST_LIST object adds the group address and is sent in messages addressed to the RSVP next hop. The MESSAGE_ID MCAST_LIST is normally used on point-to-point links.
MESSAGE_ID LIST对象用于刷新单播会话的所有Resv状态和路径状态。它由最初在Message_ID对象中公布的Message_标识符字段列表组成。其他两个对象用于刷新多播会话的路径状态。接收多播路径状态摘要刷新的节点有时需要源和组信息。这两个对象提供了此信息。对象所包含的信息和发送方式不同。两者都携带消息标识符字段和相应的源IP地址。消息\u ID SRC\u列表以消息的形式发送到会话的多播IP地址。MESSAGE_ID MCAST_LIST对象添加组地址，并以消息的形式发送到下一跳的RSVP。消息\u ID MCAST\u列表通常用于点到点链接。
An RSVP node receiving an Srefresh message, matches each listed Message_Identifier field with installed Path or Resv state. All matching state is updated as if a normal RSVP refresh message has been received. If matching state cannot be found, then the Srefresh message sender is notified via a refresh NACK.
接收Srefresh消息的RSVP节点将列出的每个消息_标识符字段与已安装的路径或Resv状态匹配。所有匹配状态都会更新，就像收到了正常的RSVP刷新消息一样。如果找不到匹配状态，则会通过刷新NACK通知Srefresh消息发送者。
A refresh NACK is sent via the MESSAGE_ID_NACK object. As described in the previous section, the rules for sending a MESSAGE_ID_NACK object are the same as for sending a MESSAGE_ID_ACK object. This includes sending MESSAGE_ID_NACK object both piggy-backed in unrelated RSVP messages or in RSVP ACK messages.
刷新NACK通过消息_ID_NACK对象发送。如前一节所述，发送消息\u ID\u NACK对象的规则与发送消息\u ID\u ACK对象的规则相同。这包括在不相关的RSVP消息或RSVP ACK消息中发送消息\u ID\u NACK对象。
MESSAGE_ID LIST object
消息ID列表对象
MESSAGE_ID_LIST Class = 25
消息\u ID\u列表类=25
Class = MESSAGE_ID_LIST Class, C_Type = 1
类=消息\u ID\u列表类，C\u类型=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits
标志：8位
No flags are currently defined. This field MUST be zero on transmission and ignored on receipt.
当前未定义任何标志。此字段在传输时必须为零，在接收时必须忽略。
Epoch: 24 bits
纪元：24位
The Epoch field from the MESSAGE_ID object corresponding to the trigger message that advertised the state being refreshed.
消息_ID对象中的历元字段，该对象对应于播发正在刷新状态的触发器消息。
Message_Identifier: 32 bits
消息标识符：32位
The Message_Identifier field from the MESSAGE_ID object corresponding to the trigger message that advertised the state being refreshed. One or more Message_Identifiers may be included.
消息ID对象中的消息标识符字段，该对象对应于通告正在刷新状态的触发器消息。可以包括一个或多个消息标识符。
IPv4/MESSAGE_ID SRC_LIST object
IPv4/MESSAGE\u ID SRC\u列表对象
Class = MESSAGE_ID_LIST Class, C_Type = 2
类=消息\u ID\u列表类，C\u类型=2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_ |
| Message_Identifier_Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_ |
| Message_Identifier_Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_ |
| Message_Identifier_Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_ |
| Message_Identifier_Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where a Source_Message_Identifier_Tuple consists of:
其中，源消息标识符元组包括：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6/MESSAGE_ID SRC_LIST object
IPv6/MESSAGE\u ID SRC\u列表对象
Class = MESSAGE_ID_LIST Class, C_Type = 3
类=消息\u ID\u列表类，C\u类型=3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6_Source_ |
| Message_Identifier_Tuple |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6_Source_ |
| Message_Identifier_Tuple |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6_Source_ |
| Message_Identifier_Tuple |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6_Source_ |
| Message_Identifier_Tuple |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where a IPv6 Source_Message_Identifier_Tuple consists of:
其中，IPv6源\消息\标识符\元组包括：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Source_IP_Address |
| (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Source_IP_Address |
| (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits
标志：8位
No flags are currently defined. This field MUST be zero on transmission and ignored on receipt.
当前未定义任何标志。此字段在传输时必须为零，在接收时必须忽略。
Epoch: 24 bits
纪元：24位
The Epoch field from the MESSAGE_ID object corresponding to the trigger message that advertised the state being refreshed.
消息_ID对象中的历元字段，该对象对应于播发正在刷新状态的触发器消息。
Message_Identifier
消息标识符
The Message_Identifier field from the MESSAGE_ID object corresponding to the trigger message that advertised the Path state being refreshed. One or more Message_Identifiers may be included. Each Message_Identifier MUST be followed by the source IP address corresponding to the sender described in the Path state being refreshed.
消息ID对象中的消息标识符字段，该对象对应于通告正在刷新的路径状态的触发器消息。可以包括一个或多个消息标识符。每个消息_标识符后面必须跟有与正在刷新的路径状态中描述的发送方对应的源IP地址。
Source_IP_Address
源IP地址
The IP address corresponding to the sender of the Path state being refreshed.
与正在刷新的路径状态的发送方对应的IP地址。
IPv4/MESSAGE_ID MCAST_LIST object
IPv4/消息ID MCAST\U列表对象
Class = MESSAGE_ID_LIST Class, C_Type = 4
类=消息\u ID\u列表类，C\u类型=4
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast_ |
| Message_Identifier_ |
| Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast_ |
| Message_Identifier_ |
| Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast_ |
| Message_Identifier_ |
| Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast_ |
| Message_Identifier_ |
| Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where a Multicast_Message_Identifier_Tuple consists of:
其中，多播消息标识符元组包括：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6/MESSAGE_ID MCAST_LIST object
IPv6/消息ID MCAST\U列表对象
Class = MESSAGE_ID_LIST Class, C_Type = 5
类=消息\u ID\u列表类，C\u类型=5
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| IPv6 Multicast_ |
| Message_Identifier_ |
| Tuple |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| IPv6 Multicast_ |
| Message_Identifier_ |
| Tuple |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| IPv6 Multicast_ |
| Message_Identifier_ |
| Tuple |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| IPv6 Multicast_ |
| Message_Identifier_ |
| Tuple |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where a IPv6 Multicast_Message_Identifier_Tuple consists of:
其中，IPv6多播\消息\标识符\元组包括：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Source_IP_Address |
| (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Destination_IP_Address |
| (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Source_IP_Address |
| (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Destination_IP_Address |
| (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits
标志：8位
No flags are currently defined. This field MUST be zero on transmission and ignored on receipt.
当前未定义任何标志。此字段在传输时必须为零，在接收时必须忽略。
Epoch: 24 bits
纪元：24位
The Epoch field from the MESSAGE_ID object corresponding to the trigger message that advertised the state being refreshed.
消息_ID对象中的历元字段，该对象对应于播发正在刷新状态的触发器消息。
Message_Identifier: 32 bits
消息标识符：32位
The Message_Identifier field from the MESSAGE_ID object corresponding to the trigger message that advertised the Path state being refreshed. One or more Message_Identifiers may be included. Each Message_Identifier MUST be followed by the source IP address corresponding to the sender of the Path state being refreshed, and the destination IP address of the session.
消息ID对象中的消息标识符字段，该对象对应于通告正在刷新的路径状态的触发器消息。可以包括一个或多个消息标识符。每个消息_标识符后面必须跟有与正在刷新的路径状态的发送方对应的源IP地址，以及会话的目标IP地址。
Source_IP_Address
源IP地址
The IP address corresponding to the sender of the Path state being refreshed.
与正在刷新的路径状态的发送方对应的IP地址。
Destination_IP_Address
目的地IP地址
The destination IP address corresponding to the session of the Path state being refreshed.
与正在刷新的路径状态的会话相对应的目标IP地址。
Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST objects. MESSAGE_ID LIST and MESSAGE_ID MCAST_LIST objects MAY be carried in the same Srefresh message. MESSAGE_ID SRC_LIST can not be combined in Srefresh messages with the other objects. A single Srefresh message MAY refresh both Path and Resv state.
Srefresh消息包含一个或多个MESSAGE_ID LIST、MESSAGE_ID SRC_LIST和MESSAGE_ID MCAST_LIST对象。MESSAGE_ID LIST和MESSAGE_ID MCAST_LIST对象可以在同一条Srefresh消息中携带。消息\u ID SRC\u列表不能与其他对象组合在Srefresh消息中。单个Srefresh消息可以刷新路径和Resv状态。
Srefresh messages carrying Message_Identifier fields corresponding to Path state are normally sent with a destination IP address equal to the address carried in the corresponding SESSION objects. The destination IP address MAY be set to the RSVP next hop when the next hop is known to be RSVP capable and either (a) the session is unicast or (b) the outgoing interface is a point-to-point link. Srefresh messages carrying Message_Identifier fields corresponding to Resv state MUST be sent with a destination IP address set to the Resv state's previous hop.
Srefresh消息中包含与路径状态对应的消息标识符字段，通常使用与相应会话对象中包含的地址相同的目标IP地址发送。当已知下一跳具有RSVP能力且（a）会话为单播或（b）传出接口为点对点链路时，可将目标IP地址设置为RSVP下一跳。发送带有与Resv状态对应的消息标识符字段的Srefresh消息时，必须将目标IP地址设置为Resv状态的上一个跃点。
Srefresh messages sent to a multicast session's destination IP address, MUST contain MESSAGE_ID SRC_LIST objects and MUST NOT include any MESSAGE_ID LIST or MESSAGE_ID MCAST_LIST objects. Srefresh messages sent to the RSVP next hop MAY contain either or both MESSAGE_ID LIST and MESSAGE_ID MCAST_LIST objects, but MUST NOT include any MESSAGE_ID SRC_LIST objects.
发送到多播会话的目标IP地址的Srefresh消息必须包含MESSAGE_ID SRC_LIST对象，并且不得包含任何MESSAGE_ID LIST或MESSAGE_ID MCAST_LIST对象。发送到RSVP下一跳的Srefresh消息可能包含MESSAGE_ID LIST和MESSAGE_ID MCAST_LIST对象中的一个或两个，但不得包含任何MESSAGE_ID SRC_LIST对象。
The source IP address of an Srefresh message is an address of the node that generates the message. The source IP address MUST match the address associate with the MESSAGE_ID objects when they were included in a standard RSVP message. As previously mentioned, the source address associated with a MESSAGE_ID object is represented in a per RSVP message type specific fashion. For messages with RSVP_HOP objects, such as Path and Resv messages, the address is found in the RSVP_HOP object. For other messages, such as ResvConf message, the associated IP address is the source address in the IP header.
Srefresh消息的源IP地址是生成消息的节点的地址。源IP地址必须与包含在标准RSVP消息中的消息\u ID对象关联的地址匹配。如前所述，与MESSAGE_ID对象关联的源地址以每RSVP消息类型特定的方式表示。对于带有RSVP_-HOP对象的消息，例如Path和Resv消息，地址位于RSVP_-HOP对象中。对于其他消息，如ResvConf消息，关联的IP地址是IP头中的源地址。
Srefresh messages that are addressed to a session's destination IP address MUST be sent with the Router Alert IP option in their IP headers. Srefresh messages addressed directly to RSVP neighbors SHOULD NOT be sent with the Router Alert IP option in their IP headers.
Srefresh发送到会话目标IP地址的消息时，必须在其IP头中使用路由器警报IP选项。直接发送至RSVP邻居的Srefresh消息不应在其IP头中使用路由器警报IP选项发送。
Each Srefresh message MUST occupy exactly one IP datagram. If it exceeds the MTU, the datagram is fragmented by IP and reassembled at the recipient node. Srefresh messages MAY be sent within an RSVP Bundle messages. Although this is not expected since Srefresh
每个Srefresh消息必须正好占用一个IP数据报。如果超过MTU，数据报将被IP分段并在接收方节点重新组装。Srefresh消息可以在RSVP消息包中发送。虽然这不是自Srefresh以来的预期
messages can carry a list of Message_Identifier fields within a single object. Implementations may choose to limit each Srefresh message to the MTU size of the outgoing link, e.g., 1500 bytes.
消息可以在单个对象中携带消息标识符字段的列表。实现可以选择将每个Srefresh消息限制为传出链路的MTU大小，例如1500字节。
The Srefresh message format is:
Srefresh消息格式为：
<Srefresh Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<srefresh list> | <source srefresh list>
<Srefresh Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<srefresh list> | <source srefresh list>
<srefresh list> ::= <MESSAGE_ID LIST> | <MESSAGE_ID MCAST_LIST>
[ <srefresh list> ]
<srefresh list> ::= <MESSAGE_ID LIST> | <MESSAGE_ID MCAST_LIST>
[ <srefresh list> ]
<source srefresh list> ::= <MESSAGE_ID SRC_LIST>
[ <source srefresh list> ]
<source srefresh list> ::= <MESSAGE_ID SRC_LIST>
[ <source srefresh list> ]
For Srefresh messages, the Msg Type field of the Common Header MUST be set to 15.
对于Srefresh消息，公共标头的Msg Type字段必须设置为15。
An Srefresh message may be generated to refresh Resv and Path state. If an Srefresh message is used to refresh some particular state, then the generation of a standard refresh message for that particular state SHOULD be suppressed. A state's refresh interval is not affected by the use of Srefresh message based refreshes.
可以生成Srefresh消息以刷新Resv和路径状态。如果使用Srefresh消息刷新某些特定状态，则应禁止为该特定状态生成标准刷新消息。使用基于Srefresh消息的刷新不会影响状态的刷新间隔。
When generating an Srefresh message, a node SHOULD refresh as much Path and Resv state as is possible by including the information from as many MESSAGE_ID objects in the same Srefresh message. Only the information from MESSAGE_ID objects that meet the source and destination IP address restrictions, as described in Sections 5.2, may be included in the same Srefresh message. Identifying Resv state that can be refreshed using the same Srefresh message is fairly straightforward. Identifying which Path state may be included is a little more complex.
生成Srefresh消息时，节点应通过在同一Srefresh消息中包含来自尽可能多的message_ID对象的信息，尽可能多地刷新路径和Resv状态。如第5.2节所述，只有来自满足源和目标IP地址限制的MESSAGE_ID对象的信息才能包含在同一Srefresh消息中。识别可以使用相同的Srefresh消息刷新的Resv状态相当简单。识别可能包含的路径状态稍微复杂一些。
Only state that was previously advertised in Path and Resv messages containing MESSAGE_ID objects can be refreshed via an Srefresh message. Srefresh message based refreshes must preserve the state synchronization properties of Path or Resv message based refreshes. Specifically, the use of Srefresh messages MUST NOT result in state being timed-out at the RSVP next hop. The period at which state is refreshed when using Srefresh messages MAY be shorter than the period that would be used when using Path or Resv message based refreshes, but it MUST NOT be longer.
只有先前在包含消息\u ID对象的Path和Resv消息中播发的状态才能通过Srefresh消息刷新。Srefresh基于消息的刷新必须保留Path或Resv基于消息的刷新的状态同步属性。具体而言，使用Srefresh消息不得导致状态在RSVP下一跳时超时。使用Srefresh消息时刷新状态的时间段可能比使用基于路径或Resv消息的刷新时使用的时间段短，但不能更长。
The particular approach used to trigger Srefresh message based refreshes is implementation specific. Some possibilities are triggering Srefresh message generation based on each state's refresh period or, on a per interface basis, periodically generating Srefresh messages to refresh all state that has not been refreshed within the state's refresh interval. Other approaches are also possible. A default Srefresh message generation interval of 30 seconds is suggested for nodes that do not dynamically calculate a generation interval.
用于触发基于Srefresh消息的刷新的特定方法是特定于实现的。一些可能性是基于每个状态的刷新周期触发Srefresh消息生成，或者基于每个接口定期生成Srefresh消息，以刷新状态刷新间隔内未刷新的所有状态。其他方法也是可能的。对于不动态计算生成间隔的节点，建议将默认的Srefresh消息生成间隔设置为30秒。
When generating an Srefresh message, there are two methods for identifying which Path state may be refreshed in a specific message. In both cases, the previously mentioned refresh interval and source IP address restrictions must be followed. The primary method is to include only those sessions that share the same destination IP address in the same Srefresh message.
生成Srefresh消息时，有两种方法可用于标识特定消息中可能刷新的路径状态。在这两种情况下，必须遵守前面提到的刷新间隔和源IP地址限制。主要方法是在同一条Srefresh消息中仅包含共享相同目标IP地址的会话。
The secondary method for identifying which Path state may be refreshed within a single Srefresh message is an optimization. This method MAY be used when the next hop is known to support RSVP and when either (a) the session is unicast or (b) the outgoing interface is a point-to-point link. This method MUST NOT be used when the next hop is not known to support RSVP or when the outgoing interface is to a multi-access network and the session is to a multicast address. The use of this method MAY be administratively configured. When using this method, the destination address in the IP header of the Srefresh message is usually the next hop's address. When the use of this method is administratively configured, the destination address should be the well known group address 224.0.0.14. When the outgoing interface is a point-to-point link, all Path state associated with sessions advertised out the interface SHOULD be included in the same Srefresh message. When the outgoing interface is not a point-to-point link, all unicast session Path state SHOULD be included in the same Srefresh message.
用于识别在单个Srefresh消息中可刷新的路径状态的第二种方法是优化。当已知下一跳支持RSVP，且（a）会话为单播或（b）传出接口为点对点链路时，可使用此方法。如果不知道下一跳是否支持RSVP，或者传出接口连接到多址网络且会话连接到多播地址，则不得使用此方法。此方法的使用可以通过管理配置。使用此方法时，Srefresh消息的IP头中的目标地址通常是下一个跃点的地址。当以管理方式配置此方法的使用时，目标地址应为众所周知的组地址224.0.0.14。当传出接口是点对点链接时，所有与在接口外播发的会话相关联的路径状态都应包含在同一条Srefresh消息中。当传出接口不是点到点链路时，所有单播会话路径状态都应包含在同一Srefresh消息中。
Identifying which Resv state may be refreshed within a single Srefresh message is based simply on the source and destination IP addresses. Any state that was previously advertised in Resv messages with the same IP addresses as an Srefresh message MAY be included.
识别单个Srefresh消息中可能刷新的Resv状态仅基于源和目标IP地址。可以包括先前在Resv消息中以与Srefresh消息相同的IP地址播发的任何状态。
After identifying the Path and Resv state that can be included in a particular Srefresh message, the message generator adds to the message MESSAGE_ID information matching each identified state's previously used object. For all Resv state and for Path state of unicast sessions, the information is added to the message in a MESSAGE_ID LIST object that has a matching Epoch value. (Note only one Epoch value will be in use during normal operation.) If no matching object exists, then a new MESSAGE_ID LIST object is created.
在识别出可包含在特定Srefresh消息中的路径和Resv状态后，消息生成器会向消息添加与每个已识别状态先前使用的对象相匹配的信息。对于所有Resv状态和单播会话的路径状态，信息将添加到具有匹配历元值的message_ID LIST对象中的消息中。（注意，在正常操作过程中，仅使用一个历元值。）如果不存在匹配的对象，则会创建一个新的MESSAGE_ID LIST对象。
Path state of multicast sessions may be added to the same message when the destination address of the Srefresh message is the RSVP next hop and the outgoing interface is a point-to-point link. In this case the information is added to the message in a MESSAGE_ID MCAST_LIST object that has a matching Epoch value. If no matching object exists, then a new MESSAGE_ID MCAST_LIST object is created. When the destination address of the message is a multicast address, then identified information is added to the message in a MESSAGE_ID SRC_LIST object that has a matching Epoch value. If no matching object exists, then a new MESSAGE_ID SRC_LIST object is created. Once the Srefresh message is composed, the message generator transmits the message out the proper interface.
当Srefresh消息的目标地址是RSVP next hop并且传出接口是点对点链路时，可以将多播会话的路径状态添加到同一消息中。在这种情况下，信息将添加到具有匹配历元值的message_ID MCAST_LIST对象中的消息中。如果不存在匹配的对象，则会创建一个新的消息ID MCAST列表对象。当消息的目标地址是多播地址时，标识信息将添加到具有匹配历元值的message_ID SRC_LIST对象中的消息中。如果不存在匹配的对象，则会创建一个新的MESSAGE\u ID SRC\u LIST对象。编写Srefresh消息后，消息生成器将消息发送到适当的接口。
Upon receiving an Srefresh message, the node MUST attempt to identify matching installed Path or Resv state. Matching is done based on the source address in the IP header of the Srefresh message, the object type and each Message_Identifier field. If matching state can be found, then the receiving node MUST update the matching state information as if a standard refresh message had been received. If matching state cannot be identified, then an Srefresh NACK MUST be generated corresponding to the unmatched Message_Identifier field. Message_Identifier fields received in MESSAGE_ID LIST objects may correspond to any Resv state or to Path state of unicast sessions. Message_Identifier fields received in MESSAGE_ID SRC_LIST or MCAST_LIST objects correspond to Path state of multicast sessions.
在收到Srefresh消息后，节点必须尝试标识匹配的已安装路径或Resv状态。根据Srefresh消息的IP头中的源地址、对象类型和每个消息的\u标识符字段进行匹配。如果可以找到匹配状态，则接收节点必须更新匹配状态信息，就像接收到标准刷新消息一样。如果无法识别匹配状态，则必须生成对应于未匹配消息_标识符字段的Srefresh NACK。在Message_ID LIST对象中接收的Message_标识符字段可以对应于任何Resv状态或单播会话的路径状态。在Message_ID SRC_LIST或MCAST_LIST对象中接收的Message_标识符字段对应于多播会话的路径状态。
An additional check must be performed to determine if a NACK should be generated for unmatched Message_Identifier fields associated with Path state of multicast sessions, i.e., fields that were carried in MESSAGE_ID SRC_LIST or MCAST_LIST objects. The receiving node must check to see if the node would forward data packets originated from the source corresponding to the unmatched field. This check, commonly known as an RPF check, is performed based on the source and group information carried in the MESSAGE_ID SRC_LIST and MCAST_LIST objects. In both objects the IP address of the source is listed immediately after the corresponding Message_Identifier field. The group address is listed immediately after the source IP address in MESSAGE_ID MCAST_LIST objects. The group address is the message's destination IP address when MESSAGE_ID SRC_LIST objects are used. The receiving node only generates an Srefresh NACK when the node would forward packets to the identified group from the listed sender. If the node would forward multicast data packets from a listed sender and there is a corresponding unmatched Message_Identifier field, then an appropriate Srefresh NACK MUST be generated. If the node would not forward packets to the identified group from a listed sender, a corresponding unmatched Message_Identifier field is silently ignored.
必须执行附加检查，以确定是否应为与多播会话的路径状态相关联的不匹配的消息标识符字段生成NACK，即消息ID SRC_列表或MCAST_列表对象中携带的字段。接收节点必须检查节点是否转发来自对应于不匹配字段的源的数据包。此检查（通常称为RPF检查）基于消息\u ID SRC\u LIST和MCAST\u LIST对象中包含的源和组信息执行。在这两个对象中，源的IP地址紧跟在相应的Message_Identifier字段之后。组地址列在消息\u ID MCAST\u LIST对象中源IP地址的后面。当使用message\u ID SRC\u LIST对象时，组地址是消息的目标IP地址。当接收节点将数据包从列出的发送方转发到标识的组时，接收节点仅生成Srefresh NACK。如果节点将转发来自所列发送方的多播数据包，并且存在相应的不匹配消息\ u标识符字段，则必须生成适当的Srefresh-NACK。如果节点不将数据包从列出的发送方转发到标识的组，则相应的不匹配消息\u标识符字段将被静默忽略。
Srefresh NACKs are used to indicate that a received Message_Identifier field carried in MESSAGE_ID LIST, SRC_LIST, or MCAST_LIST object does not match any installed state. This may occur for a number of reasons including, for example, a route change. An Srefresh NACK is encoded in a MESSAGE_ID_NACK object. When generating an Srefresh NACK, the epoch and Message_Identifier fields of the MESSAGE_ID_NACK object MUST have the same value as was received. MESSAGE_ID_NACK objects are transmitted as described in Section 4.6.
Srefresh nack用于指示Message_ID LIST、SRC_LIST或MCAST_LIST对象中包含的received Message_Identifier字段与任何已安装状态不匹配。发生这种情况的原因有很多，例如，包括路线变更。Srefresh NACK编码在MESSAGE_ID_NACK对象中。生成Srefresh NACK时，Message_ID_NACK对象的历元和Message_标识符字段必须与接收到的值相同。消息_ID_NACK对象按照第4.6节所述进行传输。
Received MESSAGE_ID_NACK objects indicate that the object generator does not have any installed state matching the object. Upon receiving a MESSAGE_ID_NACK object, the receiver performs an installed Path or Resv state lookup based on the Epoch and Message_Identifier values contained in the object. If matching state is found, then the receiver MUST transmit the matching state via a standard Path or Resv message. If the receiver cannot identify any installed state, then no action is required.
收到的消息_ID_NACK objects表明对象生成器没有任何与对象匹配的安装状态。在接收到消息_ID_NACK对象时，接收器基于对象中包含的历元和消息_标识符值执行安装路径或Resv状态查找。如果找到匹配状态，则接收器必须通过标准路径或Resv消息传输匹配状态。如果接收器无法识别任何已安装状态，则无需执行任何操作。
As discussed in [RFC2205], RSVP uses soft state to address a large class of potential errors. RSVP does this by periodically sending a full representation of installed state in Resv and Path messages. Srefresh messages are used in place of the periodic sending of standard Path and Resv refresh messages. While this provides scaling benefits and protects against common network events such as packet loss or routing change, it does not provide exactly the same error recovery properties. An example error that could potentially be recovered from via standard messages but not with Srefresh messages is internal corruption of state. This section recommends two methods that can be used to better preserve RSVP's soft state error recovery mechanism. Both mechanisms are supported using existing protocol messages.
如[RFC2205]中所述，RSVP使用软状态来解决一大类潜在错误。RSVP通过定期在Resv和Path消息中发送安装状态的完整表示来实现这一点。使用Srefresh消息代替定期发送标准路径和Resv刷新消息。虽然这提供了扩展优势并防止常见网络事件（如数据包丢失或路由更改），但它并没有提供完全相同的错误恢复属性。一个可能通过标准消息而不是Srefresh消息从中恢复的示例错误是状态的内部损坏。本节推荐两种方法，可用于更好地保留RSVP的软状态错误恢复机制。使用现有协议消息支持这两种机制。
The first mechanism uses a checksum or other algorithm to detect a previously unnoticed change in internal state. This mechanism does not protect against internal state corruption. It just covers the case where a trigger message should have been sent, but was not. When sending a Path or Resv trigger message, a node should run a checksum or other algorithm, such as [MD5], over the internal state and store the result. The choice of algorithm is an administrative decision. Periodically the node should rerun the algorithm and compare the new result with the stored result. If the values differ, then a corresponding standard Path or Resv refresh message should be
第一种机制使用校验和或其他算法来检测先前未被注意到的内部状态变化。这一机制不能防止国家内部腐败。它只涉及触发消息本应发送但未发送的情况。发送Path或Resv触发器消息时，节点应在内部状态上运行校验和或其他算法，如[MD5]，并存储结果。算法的选择是一项行政决策。节点应定期重新运行算法，并将新结果与存储的结果进行比较。如果值不同，则应显示相应的标准路径或Resv刷新消息
sent and the new value should be stored. The recomputation period should be set based on the computation resources of the node and the reliability requirements of the network.
已发送并应存储新值。重新计算周期应根据节点的计算资源和网络的可靠性要求进行设置。
The second mechanism is simply to periodically send standard Path and Resv refresh messages. Since this mechanism uses standard refresh messages, it can recover from the same set of errors as standard RSVP. When using this mechanism, the period that standard refresh messages are sent must be longer than the interval that Srefresh messages are generated in order to gain the benefits of using the summary refresh extension. When a standard refresh message is sent, a corresponding summary refresh SHOULD NOT be sent during the same refresh period. When a node supports the periodic generation of standard refresh messages while Srefreshes are being used, the frequency of generation of standard refresh messages relative to the generation of summary refreshes SHOULD be configurable by the network administrator.
第二种机制只是定期发送标准路径和Resv刷新消息。由于此机制使用标准刷新消息，因此它可以从与标准RSVP相同的错误集中恢复。使用此机制时，发送标准刷新消息的时间段必须大于生成Srefresh消息的时间间隔，以便获得使用摘要刷新扩展的好处。发送标准刷新消息时，不应在同一刷新期间发送相应的摘要刷新。当使用srefresh时，节点支持定期生成标准刷新消息时，网络管理员应可配置相对于生成摘要刷新的标准刷新消息的生成频率。
Nodes supporting the summary refresh extension advertise their support via the Refresh-Reduction-Capable bit in the RSVP message header. This enables nodes supporting the extension to detect each other. When it is not known if a next hop supports the extension, standard Path and Resv message based refreshes MUST be used. Note that when the routing next hop does not support RSVP, it will not always be possible to detect if the RSVP next hop supports the summary refresh extension. Therefore, when the routing next hop is not RSVP capable the Srefresh message based refresh SHOULD NOT be used. A node MAY be administratively configured to use Srefresh messages in all cases when all RSVP nodes in a network are known to support the summary refresh extension. This is useful since when operating in this mode, the extension properly adjusts to the case of non-RSVP next hops and changes in routing.
支持摘要刷新扩展的节点通过RSVP消息头中支持刷新减少的位来公布其支持。这使支持扩展的节点能够相互检测。如果不知道下一跳是否支持扩展，则必须使用标准路径和基于Resv消息的刷新。请注意，当路由下一跃点不支持RSVP时，并不总是能够检测RSVP下一跃点是否支持摘要刷新扩展。因此，当路由下一跳不支持RSVP时，不应使用基于Srefresh消息的刷新。当已知网络中的所有RSVP节点都支持摘要刷新扩展时，节点可被管理地配置为在所有情况下使用Srefresh消息。这很有用，因为在这种模式下操作时，扩展会根据非RSVP下一跳和路由更改的情况进行适当调整。
Per section 2, nodes supporting the summary refresh extension must also take care to recognize when a next hop stops sending RSVP messages with the Refresh-Reduction-Capable bit set.
根据第2节，支持摘要刷新扩展的节点还必须注意识别下一跳何时停止发送具有刷新减少功能位集的RSVP消息。
This section is based on [Pan] and provides procedures to implement exponential back-off for retransmission of messages awaiting acknowledgment, see Section 4.5. Implementations MUST use the described procedures or their equivalent.
本节以[Pan]为基础，并提供了实现指数退避的程序，以重新传输等待确认的消息，见第4.5节。实现必须使用所描述的过程或其等效过程。
The following is one possible mechanism for exponential back-off retransmission of an unacknowledged RSVP message: When sending such a message, a node inserts a MESSAGE_ID object with the ACK_Desired flag set. The sending node will retransmit the message until a message acknowledgment is received or the message has been transmitted a maximum number of times. Upon reception, a receiving node acknowledges the arrival of the message by sending back a message acknowledgment (that is, a corresponding MESSAGE_ID_ACK object.) When the sending node receives the acknowledgment retransmission of the message is stopped. The interval between retransmissions is governed by a rapid retransmission timer. The rapid retransmission timer starts at a small interval and increases exponentially until it reaches a threshold.
以下是未确认的RSVP消息的指数退避重传的一种可能机制：当发送此类消息时，节点插入设置了ACK_所需标志的message_ID对象。发送节点将重新传输消息，直到收到消息确认或消息已被传输最大次数。在接收时，当发送节点接收到消息的确认时，接收节点通过发送回消息确认（即，相应的消息_ID _ACK对象）来确认消息的到达。消息的重新传输停止。重传之间的间隔由快速重传计时器控制。快速重传计时器以很小的间隔启动，并以指数方式增加，直到达到阈值。
The described procedures make use of the following time parameters. All parameters are per interface.
所述程序使用以下时间参数。所有参数均为每个接口。
Rapid retransmission interval Rf:
快速重传间隔Rf：
Rf is the initial retransmission interval for unacknowledged messages. After sending the message for the first time, the sending node will schedule a retransmission after Rf seconds. The value of Rf could be as small as the round trip time (RTT) between a sending and a receiving node, if known.
Rf是未确认消息的初始重传间隔。在第一次发送消息之后，发送节点将在Rf秒之后安排重传。如果已知，Rf的值可以与发送节点和接收节点之间的往返时间（RTT）一样小。
Rapid retry limit Rl:
快速重试限制Rl:
Rl is the maximum number of times a message will be transmitted without being acknowledged.
Rl是消息在未被确认的情况下传输的最大次数。
Increment value Delta:
增量值增量：
Delta governs the speed with which the sender increases the retransmission interval. The ratio of two successive retransmission intervals is (1 + Delta).
增量控制发送方增加重传间隔的速度。两个连续重传间隔的比率为（1+Delta）。
Suggested default values are an initial retransmission timeout (Rf) of 500ms, a power of 2 exponential back-off (Delta = 1) and a retry limit (Rl) of 3.
建议的默认值为500毫秒的初始重传超时（Rf）、2倍指数退避（增量=1）和3倍的重试限制（Rl）。
After a sending node transmits a message containing a MESSAGE_ID object with the ACK_Desired flag set, it should immediately schedule a retransmission after Rf seconds. If a corresponding MESSAGE_ID_ACK object is received earlier than Rf seconds, then retransmission SHOULD be canceled. Otherwise, it will retransmit the message after (1 + Delta)*Rf seconds. The staged retransmission will continue until either an appropriate MESSAGE_ID_ACK object is received, or the rapid retry limit, Rl, has been reached.
发送节点发送包含设置了ACK_所需标志的message_ID对象的消息后，应立即在Rf秒后安排重传。如果在Rf秒之前收到相应的消息\u ID\u ACK对象，则应取消重传。否则，它将在（1+增量）*射频秒后重新传输消息。分段重新传输将继续，直到接收到适当的消息_ID _ACK对象，或者达到快速重试限制Rl为止。
A sending node can use the following algorithm when transmitting a message containing a MESSAGE_ID object with the ACK_Desired flag set:
发送节点在发送包含设置了ACK_所需标志的message_ID对象的消息时，可以使用以下算法：
Prior to initial transmission initialize: Rk = Rf and Rn = 0
Prior to initial transmission initialize: Rk = Rf and Rn = 0
while (Rn++ < Rl) {
transmit the message;
wake up after Rk seconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged or no reply from receiver for too long: */ do any
needed clean up; exit;
while (Rn++ < Rl) {
transmit the message;
wake up after Rk seconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged or no reply from receiver for too long: */ do any
needed clean up; exit;
Asynchronously, when a sending node receives a corresponding MESSAGE_ID_ACK object, it will change the retry count, Rn, to Rl.
异步地，当发送节点接收到相应的MESSAGE_ID_ACK对象时，它会将重试计数Rn更改为Rl。
Note that the transmitting node does not advertise the use of the described exponential back-off procedures via the TIME_VALUE object.
注意，发送节点不通过TIME_值对象宣传所描述的指数退避过程的使用。
The use of exponential back-off retransmission is a new and significant addition to RSVP. It will be important to review related operations and performance experience before this document advances to Draft Standard. It will be particularly important to review experience with multicast, and any ACK implosion problems actually encountered.
指数退避重传的使用是对RSVP的一个新的重要补充。在本文件进入标准草案之前，审查相关操作和性能经验非常重要。特别重要的是回顾多播的经验，以及实际遇到的任何ACK内爆问题。
This document represents ideas and comments from the MPLS-TE design team and participants in the RSVP Working Group's interim meeting. Thanks to Bob Braden, Lixia Zhang, Fred Baker, Adrian Farrel, Roch Guerin, Kireeti Kompella, David Mankins, Henning Schulzrinne, Andreas Terzis, Lan Wang and Masanobu Yuhara for specific feedback on the various versions of the document.
本文件代表MPLS-TE设计团队和RSVP工作组临时会议参与者的想法和意见。感谢Bob Braden、Lixia Zhang、Fred Baker、Adrian Farrel、Roch Guerin、Kireeti Kompella、David Mankins、Henning Schulzrinne、Andreas Terzis、Lan Wang和Masanobu Yuhara对文件不同版本的具体反馈。
Portions of this work are based on work done by Masanobu Yuhara and Mayumi Tomikawa [Yuhara].
这项工作的一部分是基于Masanobu Yuhara和Mayumi Tomikawa[Yuhara]所做的工作。
No new security issues are raised in this document. See [RFC2205] for a general discussion on RSVP security issues.
本文档中未提出新的安全问题。有关RSVP安全问题的一般性讨论，请参见[RFC2205]。
[Pan] Pan, P., Schulzrinne, H., "Staged Refresh Timers for RSVP,"
Global Internet'97, Phoenix, AZ, November 1997.
http://www.cs.columbia.edu/~pingpan/papers/timergi.pdf
[Pan] Pan, P., Schulzrinne, H., "Staged Refresh Timers for RSVP,"
Global Internet'97, Phoenix, AZ, November 1997.
http://www.cs.columbia.edu/~pingpan/papers/timergi.pdf
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin , "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源保留协议——第1版功能规范”，RFC 22052997年9月。
[Yuhara] Yuhara, M., and M Tomikawa, "RSVP Extensions for ID-based Refreshes", Work in Progress.
[Yuhara]Yuhara，M.和M Tomikawa，“基于ID的刷新的RSVP扩展”，正在进行中。
Lou Berger LabN Consulting, LLC
Lou Berger LabN咨询有限责任公司
Phone: +1 301 468 9228
EMail: lberger@labn.net
Phone: +1 301 468 9228
EMail: lberger@labn.net
Der-Hwa Gan Juniper Networks, Inc. 1194 N. Mathilda Avenue, Sunnyvale, CA 94089
美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号德华根Juniper Networks有限公司，邮编94089
Voice: +1 408 745 2074
Email: dhg@juniper.net
Voice: +1 408 745 2074
Email: dhg@juniper.net
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
乔治斯沃诺思科系统公司，马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Ping Pan Juniper Networks, Inc. 1194 N. Mathilda Avenue, Sunnyvale, CA 94089
平盘Juniper Networks，Inc.加利福尼亚州桑尼维尔马蒂尔达大道北1194号，邮编94089
Voice: +1 408 745 3704
Email: pingpan@juniper.net
Voice: +1 408 745 3704
Email: pingpan@juniper.net
Franco Tommasi University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY
弗朗索马托马斯大学莱切，Fac。意大利莱切蒙特罗尼英格尼里亚73100
EMail: franco.tommasi@unile.it
EMail: franco.tommasi@unile.it
Simone Molendini University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY
莱切的西蒙尼莫伦蒂尼大学，Fac。意大利莱切蒙特罗尼英格尼里亚73100
EMail: molendini@ultra5.unile.it
EMail: molendini@ultra5.unile.it
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。