Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6559 IJ. Wijnands
Category: Experimental S. Venaas
ISSN: 2070-1721 Cisco Systems
M. Napierala
AT&T Labs
March 2012
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6559 IJ. Wijnands
Category: Experimental S. Venaas
ISSN: 2070-1721 Cisco Systems
M. Napierala
AT&T Labs
March 2012
A Reliable Transport Mechanism for PIM
PIM的可靠传输机制
Abstract
摘要
This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol.
本文档定义了PIM协议的可靠传输机制，用于连接/删除消息的传输。这消除了定期连接/删除消息传输和处理的需要。可靠传输机制可以使用TCP或SCTP作为传输协议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6559.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6559.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . 6
3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 6
3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 7
3.3. Interface ID . . . . . . . . . . . . . . . . . . . . . . . 8
4. Establishing Transport Connections . . . . . . . . . . . . . . 9
4.1. Connection Security . . . . . . . . . . . . . . . . . . . 11
4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 11
4.3. Actions When a Connection Goes Down . . . . . . . . . . . 13
4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 14
4.5. On-Demand versus Pre-Configured Connections . . . . . . . 14
4.6. Possible Hello Suppression Considerations . . . . . . . . 15
4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 15
5. PORT Message Definitions . . . . . . . . . . . . . . . . . . . 16
5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 18
5.2. PORT Keep-Alive Message . . . . . . . . . . . . . . . . . 19
5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1. PIM IPv4 Join/Prune Option . . . . . . . . . . . . . . 21
5.3.2. PIM IPv6 Join/Prune Option . . . . . . . . . . . . . . 21
6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 22
7. Support of Multiple Address Families . . . . . . . . . . . . . 23
8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Transport Considerations . . . . . . . . . . . . . . . . . . . 23
10. Manageability Considerations . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. PORT Port Number . . . . . . . . . . . . . . . . . . . . . 25
12.2. PORT Hello Options . . . . . . . . . . . . . . . . . . . . 25
12.3. PORT Message Type Registry . . . . . . . . . . . . . . . . 26
12.4. PORT Option Type Registry . . . . . . . . . . . . . . . . 26
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
15.1. Normative References . . . . . . . . . . . . . . . . . . . 27
15.2. Informative References . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . 6
3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 6
3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 7
3.3. Interface ID . . . . . . . . . . . . . . . . . . . . . . . 8
4. Establishing Transport Connections . . . . . . . . . . . . . . 9
4.1. Connection Security . . . . . . . . . . . . . . . . . . . 11
4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 11
4.3. Actions When a Connection Goes Down . . . . . . . . . . . 13
4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 14
4.5. On-Demand versus Pre-Configured Connections . . . . . . . 14
4.6. Possible Hello Suppression Considerations . . . . . . . . 15
4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 15
5. PORT Message Definitions . . . . . . . . . . . . . . . . . . . 16
5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 18
5.2. PORT Keep-Alive Message . . . . . . . . . . . . . . . . . 19
5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1. PIM IPv4 Join/Prune Option . . . . . . . . . . . . . . 21
5.3.2. PIM IPv6 Join/Prune Option . . . . . . . . . . . . . . 21
6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 22
7. Support of Multiple Address Families . . . . . . . . . . . . . 23
8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Transport Considerations . . . . . . . . . . . . . . . . . . . 23
10. Manageability Considerations . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. PORT Port Number . . . . . . . . . . . . . . . . . . . . . 25
12.2. PORT Hello Options . . . . . . . . . . . . . . . . . . . . 25
12.3. PORT Message Type Registry . . . . . . . . . . . . . . . . 26
12.4. PORT Option Type Registry . . . . . . . . . . . . . . . . 26
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
15.1. Normative References . . . . . . . . . . . . . . . . . . . 27
15.2. Informative References . . . . . . . . . . . . . . . . . . 28
The goals of this specification are:
本规范的目标是：
o To create a simple incremental mechanism to provide reliable PIM Join/Prune message delivery in PIM version 2 for use with PIM Sparse-Mode (PIM-SM) [RFC4601], including PIM Source-Specific Multicast (PIM-SSM), and Bidirectional PIM [RFC5015].
o 创建一个简单的增量机制，在PIM版本2中提供可靠的PIM加入/删减消息传递，用于PIM稀疏模式（PIM-SM）[RFC4601]，包括PIM源特定多播（PIM-SSM）和双向PIM[RFC5015]。
o When a router supports this specification, it need not use the reliable transport mechanism with every neighbor. It can be negotiated on a per-neighbor basis.
o 当路由器支持此规范时，它不需要对每个邻居使用可靠的传输机制。它可以在每个邻居的基础上进行协商。
The explicit non-goals of this specification are:
本规范明确的非目标是：
o Making changes to the PIM message formats as defined in [RFC4601].
o 对[RFC4601]中定义的PIM消息格式进行更改。
o Providing support for automatic switching between the reliable transport mechanism and the regular PIM mechanism defined in [RFC4601]. Two routers that are PIM neighbors on a link will always use the reliable transport mechanism if and only if both have enabled support for the reliable transport mechanism.
o 支持[RFC4601]中定义的可靠传输机制和常规PIM机制之间的自动切换。当且仅当两个路由器都启用了对可靠传输机制的支持时，作为链路上PIM邻居的两个路由器将始终使用可靠传输机制。
This document will specify how periodic Join/Prune message transmission can be eliminated by using TCP [RFC0793] or SCTP [RFC4960] as the reliable transport mechanism for Join/Prune messages. The destination port number is 8471 for both TCP and SCTP.
本文档将说明如何通过使用TCP[RFC0793]或SCTP[RFC4960]作为加入/删除消息的可靠传输机制来消除定期加入/删除消息传输。TCP和SCTP的目标端口号均为8471。
This specification enables greater scalability in terms of control-traffic overhead. However, for routers connected to multi-access links, scalability comes at the price of increased PIM state and the overhead required to maintain this state.
该规范在控制流量开销方面实现了更大的可伸缩性。然而，对于连接到多址链路的路由器，可伸缩性是以增加PIM状态和维持该状态所需的开销为代价的。
In many existing and emerging networks, particularly wireless and mobile satellite systems, link degradation due to weather, interference, and other impairments can result in temporary spikes in the packet loss rate. In these environments, periodic PIM joining can cause join latency when messages are lost, causing a retransmission only 60 seconds later. By applying a reliable transport, a lost Join is retransmitted rapidly. Furthermore, when the last user leaves a multicast group, any lost Prune is similarly repaired, and the multicast stream is quickly removed from the wireless/satellite link. Without a reliable transport, the multicast transmission could otherwise continue until it timed out, roughly 3 minutes later. As network resources are at a premium in many of these environments, rapid termination of the multicast stream is critical for maintaining efficient use of bandwidth.
在许多现有和新兴网络中，特别是在无线和移动卫星系统中，由于天气、干扰和其他损害而导致的链路退化可能会导致数据包丢失率的暂时峰值。在这些环境中，当消息丢失时，周期性PIM加入可能会导致加入延迟，导致仅在60秒后重新传输。通过应用可靠的传输，丢失的连接可以快速重新传输。此外，当最后一个用户离开多播组时，任何丢失的剪枝都会得到类似的修复，并且多播流会迅速从无线/卫星链路中删除。如果没有可靠的传输，多播传输可能会继续，直到超时，大约3分钟后。由于在许多这样的环境中，网络资源处于溢价状态，因此快速终止多播流对于保持带宽的有效使用至关重要。
This is an experimental extension to PIM. It makes some fundamental changes to how PIM works in that Join/Prune state does not require periodic updates, and it partly turns PIM into a hard-state protocol. Also, using reliable delivery for PIM messages is a new concept, and it is likely that experiences from early implementations and deployments will lead to at least minor changes in the protocol. Once there is some deployment experience, making this a Standards Track protocol should be considered. Experiments using this protocol only require support by pairs of PIM neighbors, and need not be constrained to isolated networks.
这是PIM的一个实验扩展。它对PIM在连接/删除状态下的工作方式做了一些根本性的改变，不需要定期更新，并且部分地将PIM变成了硬状态协议。此外，对PIM消息使用可靠的传递是一个新概念，早期实现和部署的经验可能会导致协议中至少有一些小的变化。一旦有了一些部署经验，就应该考虑将其作为标准跟踪协议。使用该协议的实验只需要PIM邻居对的支持，而不需要局限于孤立的网络。
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]中所述进行解释。
PORT: Stands for PIM Over Reliable Transport, which is the short form for describing the mechanism in this specification where PIM can use the TCP or SCTP transport protocol.
PORT：代表PIM Over Reliable Transport，是本规范中描述PIM可以使用TCP或SCTP传输协议的机制的缩写。
Periodic Join/Prune message: A Join/Prune message sent periodically to refresh state.
定期加入/删除消息：定期发送以刷新状态的加入/删除消息。
Incremental Join/Prune message: A Join/Prune message sent as a result of state creation or deletion events. Also known as a triggered message.
增量加入/删除消息：由于状态创建或删除事件而发送的加入/删除消息。也称为触发消息。
Native Join/Prune message: A Join/Prune message that is carried with an IP protocol type of PIM.
本机加入/删除消息：与PIM的IP协议类型一起携带的加入/删除消息。
PORT Join/Prune message: A Join/Prune message using TCP or SCTP for transport.
端口连接/删除消息：使用TCP或SCTP传输的连接/删除消息。
Datagram Mode: The procedures whereby PIM encapsulates triggered or periodic Join/Prune messages in IP packets.
数据报模式：PIM在IP数据包中封装触发或定期加入/删减消息的过程。
PORT Mode: The procedures used by PIM and defined in this specification for sending Join/Prune messages over the TCP or SCTP transport layer.
端口模式：PIM使用并在本规范中定义的通过TCP或SCTP传输层发送加入/删除消息的过程。
PIM Over Reliable Transport (PORT) is a simple extension to PIMv2 for refresh reduction of PIM Join/Prune messages. It involves sending incremental rather than periodic Join/Prune messages over a TCP/SCTP connection between PIM neighbors.
PIM Over Reliable Transport（端口）是PIMv2的一个简单扩展，用于减少PIM加入/删除消息的刷新。它涉及通过PIM邻居之间的TCP/SCTP连接发送增量而不是周期性的加入/删减消息。
PORT only applies to PIM Sparse-Mode [RFC4601] and Bidirectional PIM [RFC5015] Join/Prune messages.
端口仅适用于PIM稀疏模式[RFC4601]和双向PIM[RFC5015]加入/删除消息。
This document does not restrict PORT to any specific link types. However, the use of PORT on, e.g., multi-access LANs with many PIM neighbors should be carefully evaluated. This is due to the facts that there may be a full mesh of PORT connections and that explicit tracking of all PIM neighbors is required.
本文档不将端口限制为任何特定的链接类型。但是，应仔细评估端口的使用情况，例如具有许多PIM邻居的多址LAN。这是因为可能存在端口连接的完整网格，并且需要显式跟踪所有PIM邻居。
PORT can be incrementally used on a link between PORT-capable neighbors. Routers that are not PORT-capable can continue to use PIM in Datagram mode. PORT capability is detected using new PORT-Capable PIM Hello Options.
端口可以在支持端口的邻居之间的链路上增量使用。不支持端口的路由器可以在数据报模式下继续使用PIM。使用新的支持端口的PIM Hello选项检测端口功能。
Once PORT is enabled on an interface and a PIM neighbor also announces that it is PORT enabled, only PORT Join/Prune messages will be used. That is, only PORT Join/Prune messages are accepted from, and sent to, that particular neighbor. Native Join/Prune messages are still used for PIM neighbors that are not PORT enabled.
一旦在接口上启用了端口，并且PIM邻居也宣布该端口已启用，则只会使用端口加入/删除消息。也就是说，只有端口加入/删除消息从该特定邻居接受并发送到该邻居。未启用端口的PIM邻居仍使用本机加入/删除消息。
PORT Join/Prune messages are sent using a TCP/SCTP connection. When two PIM neighbors are PORT enabled, both for TCP or both for SCTP, they will immediately, or on demand, establish a connection. If the connection goes down, they will again immediately, or on demand, try to reestablish the connection. No Join/Prune messages (neither Native nor PORT) are sent while there is no connection. Also, any received native Join/Prune messages from that neighbor are discarded, even when the connection is down.
端口加入/删除消息使用TCP/SCTP连接发送。当两个PIM邻居都支持端口时，无论是TCP还是SCTP，它们都将立即或按需建立连接。如果连接中断，他们将立即或按要求再次尝试重新建立连接。在没有连接的情况下，不会发送加入/删除消息（既不是本机消息，也不是端口消息）。此外，从该邻居接收的任何本机加入/删减消息都将被丢弃，即使连接已断开。
When PORT is used, only incremental Join/Prune messages are sent from downstream routers to upstream routers. As such, downstream routers do not generate periodic Join/Prune messages for state for which the Reverse Path Forwarding (RPF) neighbor is PORT-capable.
当使用端口时，仅从下游路由器向上游路由器发送增量加入/删减消息。因此，下游路由器不会为反向路径转发（RPF）邻居具有端口能力的状态生成定期加入/删减消息。
For Joins and Prunes that are received over a TCP/SCTP connection, the upstream router does not start or maintain timers on the outgoing interface entry. Instead, it keeps track of which downstream routers have expressed interest. An interface is deleted from the outgoing interface list only when all downstream routers on the interface no longer wish to receive traffic. If there also are native Joins/ Prunes from a non-PORT neighbor, then a router can maintain timers on
对于通过TCP/SCTP连接接收的联接和修剪，上游路由器不会在传出接口条目上启动或维护计时器。相反，它会跟踪哪些下游路由器表示了兴趣。只有当接口上的所有下游路由器不再希望接收流量时，才会从传出接口列表中删除接口。如果还有来自非端口邻居的本机连接/删除，则路由器可以在上维护计时器
the outgoing interface entry as usual, while at the same time keep track of each of the downstream PORT Joins/Prunes.
输出接口条目与往常一样，同时跟踪每个下游端口连接/修剪。
This document does not update the PIM Join/Prune packet format. In the procedures described in this document, each PIM Join/Prune message is included in the payload of a PORT message carried over TCP/SCTP. See Section 5 for details on the PORT message.
本文档不更新PIM加入/删除数据包格式。在本文档中描述的过程中，每个PIM Join/Prune消息都包含在TCP/SCTP上携带的端口消息的有效负载中。有关端口消息的详细信息，请参见第5节。
Option Type: PIM-over-TCP-Capable
选项类型：支持TCP的PIM
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 27 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 27 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assigned Hello Type values can be found in [HELLO-OPT].
分配的Hello类型值可在[Hello-OPT]中找到。
When a router is configured to use PIM over TCP on a given interface, it MUST include the PIM-over-TCP-Capable Hello Option in its Hello messages for that interface. If a router is explicitly disabled from using PIM over TCP, it MUST NOT include the PIM-over-TCP-Capable Hello Option in its Hello messages.
当路由器配置为在给定接口上使用TCP上的PIM时，它必须在该接口的Hello消息中包含支持TCP上的PIM Hello选项。如果明确禁止路由器在TCP上使用PIM，则路由器在其Hello消息中不得包含支持PIM over TCP的Hello选项。
All Hello messages containing the PIM-over-TCP-Capable Hello Option MUST also contain the Interface ID Hello Option, see Section 3.3.
所有包含PIM over TCP功能Hello选项的Hello消息也必须包含Interface ID Hello选项，请参见第3.3节。
Implementations MAY provide a configuration option to enable or disable PORT functionality. It is RECOMMENDED that this capability be disabled by default.
实现可以提供一个配置选项来启用或禁用端口功能。建议在默认情况下禁用此功能。
Length: Length in bytes for the value part of the Type/Length/Value encoding, where X is the number of bytes that make up the Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 when AFI of value 0 is used.
长度：类型/长度/值编码的值部分的长度（以字节为单位），其中X是组成连接ID字段的字节数。当使用值为1（IPv4）[AFI]的AFI时，X为4；当使用值为2（IPv6）[AFI]的AFI时，X为16；当使用值为0的AFI时，X为0。
TCP Connection ID AFI: The AFI value to describe the address family of the address of the TCP Connection ID field. Note that this value does not need to match the address family of the PIM Hello message that carries it. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the TCP connection.
TCP连接ID AFI：用于描述TCP连接ID字段地址的地址族的AFI值。请注意，此值不需要与携带它的PIM Hello消息的地址族匹配。当此字段为0时，将使用本文档范围之外的机制获取用于建立TCP连接的地址。
Reserved: Set to zero on transmission and ignored on receipt.
保留：传输时设置为零，接收时忽略。
Exp: For experimental use [RFC3692]. One expected use of these bits would be to signal experimental capabilities. For example, if a router supports an experimental feature, it may set a bit to indicate this. The default behavior, unless a router supports a particular experiment, is to ignore the bits on receipt.
实验：供实验使用[RFC3692]。这些比特的一个预期用途是向实验能力发送信号。例如，如果路由器支持实验性功能，它可能会设置一个位来指示这一点。除非路由器支持特定的实验，否则默认行为是忽略接收到的位。
TCP Connection ID: An IPv4 or IPv6 address used to establish the TCP connection. This field is omitted (length 0) for the Connection ID AFI 0.
TCP连接ID：用于建立TCP连接的IPv4或IPv6地址。对于连接ID AFI 0，省略此字段（长度0）。
Option Type: PIM-over-SCTP-Capable
选项类型：支持PIM over SCTP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 28 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 28 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assigned Hello Type values can be found in [HELLO-OPT].
分配的Hello类型值可在[Hello-OPT]中找到。
When a router is configured to use PIM over SCTP on a given interface, it MUST include the PIM-over-SCTP-Capable Hello Option in its Hello messages for that interface. If a router is explicitly disabled from using PIM over SCTP, it MUST NOT include the PIM-over-SCTP-Capable Hello Option in its Hello messages.
当路由器配置为在给定接口上使用PIM over SCTP时，它必须在该接口的Hello消息中包含支持PIM over SCTP的Hello选项。如果明确禁止路由器使用PIM over SCTP，则路由器的Hello消息中不得包含支持PIM over SCTP的Hello选项。
All Hello messages containing the PIM-over-SCTP-Capable Hello Option MUST also contain the Interface ID Hello Option; see Section 3.3.
所有包含PIM over SCTP-Capable Hello选项的Hello消息也必须包含Interface ID Hello选项；见第3.3节。
Implementations MAY provide a configuration option to enable or disable PORT functionality. It is RECOMMENDED that this capability be disabled by default.
实现可以提供一个配置选项来启用或禁用端口功能。建议在默认情况下禁用此功能。
Length: Length in bytes for the value part of the Type/Length/Value encoding, where X is the number of bytes that make up the Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 when AFI of value 0 is used.
长度：类型/长度/值编码的值部分的长度（以字节为单位），其中X是组成连接ID字段的字节数。当使用值为1（IPv4）[AFI]的AFI时，X为4；当使用值为2（IPv6）[AFI]的AFI时，X为16；当使用值为0的AFI时，X为0。
SCTP Connection ID AFI: The AFI value to describe the address family of the address of the SCTP Connection ID field. Note that this value does not need to match the address family of the PIM Hello message that carries it. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the SCTP connection.
SCTP连接ID AFI：用于描述SCTP连接ID字段地址的地址系列的AFI值。请注意，此值不需要与携带它的PIM Hello消息的地址族匹配。当此字段为0时，将使用本文档范围之外的机制获取用于建立SCTP连接的地址。
Reserved: Set to zero on transmission and ignored on receipt.
保留：传输时设置为零，接收时忽略。
Exp: For experimental use [RFC3692]. One expected use of these bits would be to signal experimental capabilities. For example, if a router supports an experimental feature, it may set a bit to indicate this. The default behavior, unless a router supports a particular experiment, is to ignore the bits on receipt.
实验：供实验使用[RFC3692]。这些比特的一个预期用途是向实验能力发送信号。例如，如果路由器支持实验性功能，它可能会设置一个位来指示这一点。除非路由器支持特定的实验，否则默认行为是忽略接收到的位。
SCTP Connection ID: An IPv4 or IPv6 address used to establish the SCTP connection. This field is omitted (length 0) for the Connection ID AFI 0.
SCTP连接ID：用于建立SCTP连接的IPv4或IPv6地址。对于连接ID AFI 0，省略此字段（长度0）。
All Hello messages containing PIM-over-TCP-Capable or PIM-over-SCTP-Capable Hello Options MUST also contain the Interface ID Hello Option [RFC6395].
所有包含支持TCP的PIM或支持SCTP的PIM Hello选项的Hello消息也必须包含接口ID Hello选项[RFC6395]。
The Interface ID is used to associate a PORT Join/Prune message with the PIM neighbor from which it is coming. When unnumbered interfaces are used or when a single transport connection is used for sending and receiving Join/Prune messages over multiple interfaces, the Interface ID is used to convey the interface from Join/Prune message sender to Join/Prune message receiver. The value of the Interface ID Hello Option in Hellos sent on an interface MUST be the same as the Interface ID value in all PORT Join/Prune messages sent to a PIM neighbor on that interface.
接口ID用于将端口加入/删除消息与它来自的PIM邻居关联。当使用未编号的接口或使用单个传输连接通过多个接口发送和接收加入/删除消息时，接口ID用于将接口从加入/删除消息发送方传送到加入/删除消息接收方。在接口上发送的Hellos中的接口ID Hello选项的值必须与发送到该接口上的PIM邻居的所有端口连接/删除消息中的接口ID值相同。
The Interface ID need only uniquely identify an interface of a router; it does not need to identify to which router the interface belongs. This means that the Router ID part of the Interface ID MAY be 0. For details on the Router ID and the value 0, see [RFC6395].
接口ID只需唯一标识路由器的接口；它不需要识别接口属于哪个路由器。这意味着接口ID的路由器ID部分可能为0。有关路由器ID和值0的详细信息，请参阅[RFC6395]。
While a router interface is PORT enabled, a PIM-over-TCP-Capable or a PIM-over-SCTP-Capable Option MUST be included in the PIM Hello messages sent on that interface. When a router on a PORT-enabled interface receives a Hello message containing a PIM-over-TCP-Capable/ PIM-over-SCTP-Capable Option from a new neighbor, or an existing neighbor that did not previously include the option, it switches to PORT mode for that particular neighbor.
当路由器接口启用端口时，在该接口上发送的PIM Hello消息中必须包含支持TCP的PIM或支持SCTP的PIM选项。当端口启用接口上的路由器从新邻居或之前未包含该选项的现有邻居接收到包含支持TCP的PIM/SCTP的PIM选项的Hello消息时，它会切换到该特定邻居的端口模式。
When a router switches to PORT mode for a neighbor, it stops sending and accepting Native Join/Prune messages for that neighbor. Any state from previous Native Join/Prune messages is left to expire as normal. It will also attempt to establish a transport connection (TCP or SCTP) with the neighbor. If both the router and its neighbor have announced both PIM-over-TCP-Capable and PIM-over-SCTP-Capable Options, SCTP MUST be used. This resolves the issue where two transports are both offered. The method prefers SCTP over TCP, because SCTP has benefits such as handling of call collisions and support for multiple streams, as discussed later in this document.
当路由器切换到邻居的端口模式时，它停止发送和接受该邻居的本机加入/删除消息。以前的本机加入/删除消息中的任何状态都会像正常情况一样过期。它还将尝试与邻居建立传输连接（TCP或SCTP）。如果路由器及其邻居都已宣布支持TCP上的PIM和支持SCTP上的PIM选项，则必须使用SCTP。这解决了同时提供两个传输的问题。与TCP相比，该方法更倾向于使用SCTP，因为SCTP具有处理调用冲突和支持多个流等优点，本文稍后将对此进行讨论。
When the router is using TCP, it will compare the TCP Connection ID it announced in the PIM-over-TCP-Capable Option with the TCP Connection ID in the Hello received from the neighbor. Unless connections are opened on demand (see below), the router with the lower Connection ID MUST do an active transport open to the neighbor Connection ID. The router with the higher Connection ID MUST do a passive transport open. An implementation MAY open connections only on demand; in that case, it may be that the neighbor with the higher Connection ID does the active open (see Section 4.5). If the router with the lower Connection ID chooses to only do an active open on demand, it MUST do a passive open, allowing for the neighbor to initiate the connection. Note that the source address of the active open MUST be the announced Connection ID.
当路由器使用TCP时，它会将它在PIM over TCP Capable选项中宣布的TCP连接ID与从邻居收到的Hello中的TCP连接ID进行比较。除非按需打开连接（见下文），否则具有较低连接ID的路由器必须对邻居连接ID进行主动传输打开。具有较高连接ID的路由器必须进行被动传输打开。一个实现只能根据需要打开连接；在这种情况下，可能是具有较高连接ID的邻居进行了主动打开（参见第4.5节）。如果具有较低连接ID的路由器选择仅按需执行主动打开，则必须执行被动打开，以允许邻居启动连接。请注意，活动打开的源地址必须是公布的连接ID。
When the router is using SCTP, the IP address comparison need not be done since the SCTP protocol can handle call collision.
当路由器使用SCTP时，不需要进行IP地址比较，因为SCTP协议可以处理呼叫冲突。
The decisions whether to use PORT, which transport to use, and which Connection IDs to use are made independently for IPv4 and IPv6. Thus, if PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello messages MUST be sent, both containing PORT Hello Options. If two neighbors announce the same transport (TCP or SCTP) and the same Connection IDs in the IPv4 and IPv6 Hello messages, then only one connection is established and is shared. Otherwise, two connections are established and are used separately.
对于IPv4和IPv6，决定是否使用端口、使用哪个传输以及使用哪个连接ID是独立的。因此，如果端口同时用于IPv4和IPv6，则必须发送IPv4和IPv6 PIM Hello消息，这两个消息都包含端口Hello选项。如果两个邻居在IPv4和IPv6 Hello消息中宣布相同的传输（TCP或SCTP）和相同的连接ID，则只建立并共享一个连接。否则，将建立两个连接并分别使用。
The PIM router that performs the active open initiates the connection with a locally generated source transport port number and a well-known destination transport port number. The PIM router that performs the passive open listens on the well-known local transport port number and does not qualify the remote transport port number. See Section 5 for the well-known port number assignment for PORT.
执行主动开放的PIM路由器使用本地生成的源传输端口号和已知的目标传输端口号启动连接。执行被动打开的PIM路由器侦听已知的本地传输端口号，但不限定远程传输端口号。有关端口的已知端口号分配，请参见第5节。
When a transport connection is established (or reestablished), the two routers MUST both send a full set of Join/Prune messages for state for which the other router is the upstream neighbor. This is needed to ensure that the upstream neighbor has the correct state. When moving from Datagram mode, or when the connection has gone down, the router cannot be sure that all the previous Join/Prune state was received by the neighbor. Any state that was created before the connection was established (or reestablished) and that is not refreshed MUST be left to expire and be deleted. When the non-refreshed state has expired and been deleted, the two neighbors will be in sync.
当建立（或重新建立）传输连接时，两个路由器都必须针对另一个路由器是上游邻居的状态发送一组完整的加入/删除消息。这是确保上游邻居具有正确状态所必需的。当从数据报模式移动时，或者当连接断开时，路由器无法确保所有先前的加入/删除状态都已被邻居接收。任何在建立（或重新建立）连接之前创建且未刷新的状态都必须过期并删除。当非刷新状态过期并被删除时，两个邻居将同步。
When not running PORT, a full update is only needed when a router restarts; with PORT, it must be done every time a connection is established. This can be costly, although it is expected that a PORT connection will go up and down rarely. There may be a need for extensions to better handle this.
当不运行端口时，仅当路由器重新启动时才需要完全更新；对于端口，必须在每次建立连接时执行此操作。这可能代价高昂，尽管预计端口连接很少会上下波动。可能需要扩展来更好地处理这一问题。
It is possible that a router starts sending Hello messages with a new Connection ID, e.g., due to configuration changes. A router MUST always use the last announced and last seen Connection IDs. A connection is identified by the local Connection ID (the one we are announcing on a particular interface), and the remote Connection ID (the one we are receiving from a neighbor on the same interface). When either the local or remote ID changes, the Connection ID pair we need a connection for changes. There may be an existing connection with the same pair, in which case the router will share that connection. Or, a new connection may need to be established. Note that for link-local addresses, the interface should be regarded as part of the ID, so that connection sharing is not attempted when the same link-local addresses are seen on different interfaces.
路由器可能会开始发送带有新连接ID的Hello消息，例如，由于配置更改。路由器必须始终使用最后公布和最后看到的连接ID。连接由本地连接ID（我们在特定接口上宣布的ID）和远程连接ID（我们从同一接口上的邻居接收的ID）标识。当本地或远程ID发生更改时，连接ID对需要连接进行更改。可能存在同一对的现有连接，在这种情况下，路由器将共享该连接。或者，可能需要建立新的连接。请注意，对于链路本地地址，接口应视为ID的一部分，以便在不同接口上看到相同的链路本地地址时，不会尝试连接共享。
When a Connection ID changes, if the previously used connection is not needed (i.e., there are no other PIM neighborships using the same Connection ID pair), both peers MUST attempt to reset the transport connection. Next (even if the old connection is still needed), they MUST, unless a connection already exists with the new Connection ID pair, immediately or on demand attempt to establish a new connection with the new Connection ID pair.
当连接ID更改时，如果不需要以前使用的连接（即，没有其他PIM邻居使用相同的连接ID对），则两个对等方必须尝试重置传输连接。接下来（即使仍然需要旧连接），除非已经存在具有新连接ID对的连接，否则它们必须立即或按需尝试使用新连接ID对建立新连接。
Normally, the Interface ID would not change while a connection is up. However, if it does, the change does not affect the connection. It just means that when subsequent PORT Join/Prune messages are received, they should be matched against the last seen Interface ID.
正常情况下，连接启动时接口ID不会更改。但是，如果是这样，更改不会影响连接。这仅仅意味着当接收到后续的端口连接/删除消息时，它们应该与最后看到的接口ID相匹配。
Note that a Join sent over a transport connection will only be seen by the upstream router; thus, it will not cause non-PORT routers on the link with the upstream router to delay the refresh of Join state for the same state. Similarly, a Prune sent over a transport connection will only be seen by the upstream router; thus, it will never cause non-PORT routers on the link with the upstream router to send a Join to override this Prune.
请注意，通过传输连接发送的连接只会被上游路由器看到；因此，它不会导致与上游路由器的链路上的非端口路由器延迟相同状态的连接状态刷新。类似地，通过传输连接发送的剪枝只会被上游路由器看到；因此，它永远不会导致与上游路由器连接的链路上的非端口路由器发送连接以覆盖此修剪。
Note also that a datagram PIM Join/Prune message for a said (S,G) or (*,G) sent by some router on a link will not cause routers on the same link that use a transport connection with the upstream router for that state to suppress the refresh of that state to the upstream router (because they don't need to periodically refresh this state) or to send a Join to override a Prune. The latter will not occur because the upstream router will only stop forwarding the traffic when all joined routers that use a transport connection have explicitly sent a Prune for this state, as explained in Section 6.
还请注意，由链路上的某个路由器发送的所述（S，G）或（*，G）的数据报PIM Join/Prune消息不会导致同一链路上使用与该状态的上游路由器的传输连接的路由器抑制向上游路由器刷新该状态（因为它们不需要定期刷新该状态）或发送连接以覆盖修剪。后者不会发生，因为上游路由器只有在使用传输连接的所有连接路由器明确发送了该状态的修剪时才会停止转发流量，如第6节所述。
TCP/SCTP packets used for PORT MUST be sent with a TTL/Hop Limit of 255 to facilitate the enabling of the Generalized TTL Security Mechanism (GTSM) [RFC5082]. Implementations SHOULD provide a configuration option to enable the GTSM check at the receiver. This means checking that inbound packets from directly connected neighbors have a TTL/Hop Limit of 255, but implementations MAY also allow for a different TTL/Hop Limit threshold to check that the sender is within a certain number of router hops. The GTSM check SHOULD be disabled by default.
用于端口的TCP/SCTP数据包必须以255的TTL/Hop限制发送，以便于启用通用TTL安全机制（GTSM）[RFC5082]。实施应提供一个配置选项，以便在接收器处启用GTSM检查。这意味着检查来自直接连接的邻居的入站数据包的TTL/Hop限制为255，但实现也可能允许使用不同的TTL/Hop限制阈值来检查发送方是否在一定数量的路由器跃点内。默认情况下，应禁用GTSM检查。
Implementations SHOULD support the TCP Authentication Option (TCP-AO) [RFC5925] and SCTP Authenticated Chunks [RFC4895].
实现应支持TCP身份验证选项（TCP-AO）[RFC5925]和SCTP身份验证块[RFC4895]。
TCP is designed to keep connections up indefinitely during a period of network disconnection. If a PIM-over-TCP router fails, the TCP connection may stay up until the neighbor actually reboots, and even then it may continue to stay up until PORT tries to send the neighbor some information. This is particularly relevant to PIM since the flow of Join/Prune messages might be in only one direction and the downstream neighbor might never get any indication via TCP that the other end of the connection is not really there.
TCP的设计目的是在网络断开期间无限期地保持连接。如果TCP路由器上的PIM失败，TCP连接可能会一直保持，直到邻居实际重新启动，甚至可能会继续保持，直到端口尝试向邻居发送一些信息。这与PIM特别相关，因为连接/删除消息流可能只在一个方向上，而下游邻居可能永远不会通过TCP获得连接另一端不存在的任何指示。
SCTP has a heartbeat mechanism that can be used to detect that a connection is not working, even when no data is sent. Many TCP implementations also support sending keep-alives for this purpose. Implementations MAY make use of TCP keep-alives, but the PORT keep-alive mechanism defined below allows for more control and flexibility.
SCTP有一种心跳机制，可以用来检测连接是否工作，即使没有发送数据。许多TCP实现还支持为此目的发送keep-alive。实现可以使用TCP保持有效，但是下面定义的端口保持有效机制允许更多的控制和灵活性。
One can detect that a PORT connection is not working by regularly sending PORT messages. This applies to both TCP and SCTP. For example, in the case of TCP, the connection will be reset if no TCP ACKs are received after several retries. PORT in itself does not require any periodic signaling. PORT Join/Prune messages are only sent when there is a state change. If the state changes are not frequent enough, a PORT Keep-Alive message (defined in Section 5.2) can be sent instead. For example, if an implementation wants to send a PORT message, to check that the connection is working, at least every 60 seconds, then whenever 60 seconds have passed since the previous message, a Keep-Alive message could be sent. If there were less than 60 seconds between each Join/Prune, no Keep-Alive messages would be needed. Implementations SHOULD support the use of PORT Keep-Alive messages. It is RECOMMENDED that a configuration option be available to network administrators to enable it when needed. Note that Keep-Alives can be used by a peer, independently of whether the other peer supports it.
通过定期发送端口消息，可以检测到端口连接不工作。这适用于TCP和SCTP。例如，在TCP的情况下，如果在多次重试后没有收到TCP确认，则连接将被重置。端口本身不需要任何周期性信令。端口加入/删除消息仅在状态更改时发送。如果状态更改不够频繁，则可以发送端口保持活动消息（定义见第5.2节）。例如，如果一个实现想要发送一条端口消息，至少每60秒检查一次连接是否正常工作，那么只要上一条消息发出60秒，就可以发送一条保持活动的消息。如果每次加入/删除之间的间隔少于60秒，则不需要保持活动状态的消息。实现应该支持端口保持活动消息的使用。建议网络管理员提供一个配置选项，以便在需要时启用它。请注意，Keep Alives可由一个对等方使用，与另一个对等方是否支持它无关。
An implementation that supports Keep-Alive messages acts as follows when processing a received PORT message. When processing a Keep-Alive message with a non-zero Holdtime value, it MUST set a timer to the value. We call this timer Connection Expiry Timer (CET). If the CET is already running, it MUST be reset to the new value. When processing a Keep-Alive message with a zero Holdtime value, the CET (if running) MUST be stopped. When processing a PORT message other than a Keep-Alive, the CET MUST be reset to the last received Holdtime value if running. If the CET is not running, no action is taken. If the CET expires, the connection SHOULD be shut down. This specification does not mandate a specific default Holdtime value. However, the dynamic congestion and flow control in TCP and SCTP can result in variable transit delay between the endpoints. When capacity varies, there may be loss in the network or variable link performance. Consistent behavior therefore requires a sufficiently large Holdtime value, e.g., 60 seconds to prevent premature termination.
在处理接收到的端口消息时，支持保持活动消息的实现的操作如下。处理具有非零Holdtime值的Keep Alive消息时，必须将计时器设置为该值。我们称之为定时器连接到期定时器（CET）。如果CET已经运行，则必须将其重置为新值。当处理具有零Holdtime值的Keep Alive消息时，必须停止CET（如果正在运行）。当处理保持活动状态以外的端口消息时，如果运行CET，则必须将其重置为上次收到的保持时间值。如果CET未运行，则不采取任何措施。如果CET过期，应关闭连接。此规范不强制指定特定的默认保持时间值。然而，TCP和SCTP中的动态拥塞和流量控制会导致端点之间的可变传输延迟。当容量变化时，可能会导致网络损失或链路性能变化。因此，一致的行为需要足够大的保持时间值，例如60秒，以防止过早终止。
It is possible that a router receives Join/Prune messages for an interface/link that is down. As long as the neighbor has not expired, it is RECOMMENDED to process those messages as usual. If they are ignored, then the router SHOULD ensure it gets a full update
路由器可能会接收关闭接口/链路的加入/删除消息。只要邻居没有过期，建议像往常一样处理这些消息。如果它们被忽略，那么路由器应该确保它得到完整的更新
for that interface when it comes back up. This can be done by changing the GenID (Generation Identifier; see [RFC4601]) or by terminating and reestablishing the connection.
当它返回时，用于该接口。这可以通过更改GenID（生成标识符；请参见[RFC4601]）或终止并重新建立连接来实现。
If a PORT neighbor changes its GenID and a connection is established or is in the process of being established, the local side should generally tear down the connection and do as described in Section 4.3. However, if the connection is shared by multiple interfaces and the GenID changes for only one of them, the local side SHOULD simply send a full update, similar to other cases when a GenID changes for an upstream neighbor.
如果端口邻居更改了其GenID，并且建立了连接或正在建立连接，则本地侧通常应断开连接，并按照第4.3节所述进行操作。但是，如果连接由多个接口共享，并且GenID仅为其中一个接口更改，则本地端只需发送完整更新，类似于GenID为上游邻居更改时的其他情况。
A connection may go down for a variety of reasons. It may be due to an error condition or a configuration change. A connection SHOULD be shut down as soon as there are no more PIM neighbors using it. That is, for the connection in question (and its associated local and remote Connection IDs), when there is no PIM neighbor with that particular remote Connection ID on any interface where we announce the local Connection ID, the connection SHOULD be shut down. This may happen when a new Connection ID is configured, PORT is disabled, or a PIM neighbor expires.
连接可能由于各种原因而中断。这可能是由于错误条件或配置更改造成的。一旦不再有PIM邻居使用连接，就应立即关闭该连接。也就是说，对于所讨论的连接（及其关联的本地和远程连接ID），当在我们宣布本地连接ID的任何接口上没有具有该特定远程连接ID的PIM邻居时，应该关闭连接。当配置了新连接ID、端口被禁用或PIM邻居过期时，可能会发生这种情况。
If a PIM neighbor expires, one should free connection state and downstream outgoing interface list (oif-list) state for that neighbor. A downstream router, when an upstream neighboring router has expired, will simply update the RPF neighbor for the corresponding state to a new neighbor where it would trigger Join/ Prune messages. This behavior is according to [RFC4601], which defines the term "RPF neighbor". It is required of a PIM router to clear its neighbor table for a neighbor who has timed out due to neighbor Holdtime expiration.
如果PIM邻居过期，则应释放该邻居的连接状态和下游传出接口列表（oif列表）状态。当上游邻居路由器过期时，下游路由器将简单地将RPF邻居的相应状态更新为新邻居，并在新邻居处触发加入/删除消息。此行为符合[RFC4601]，其中定义了术语“RPF邻居”。PIM路由器需要为因邻居保持时间过期而超时的邻居清除其邻居表。
When a connection is no longer available between two PORT-enabled PIM neighbors, they MUST immediately, or on demand, try to reestablish the connection following the normal rules for connection establishment. The neighbors MUST also start expiry timers so that all oif-list state for the neighbor using the connection gets expired after J/P_Holdtime, unless it later gets refreshed by receiving new Join/Prunes.
当两个支持端口的PIM邻居之间的连接不再可用时，他们必须立即或根据需要尝试按照正常的连接建立规则重新建立连接。邻居还必须启动过期计时器，以便使用连接的邻居的所有oif列表状态在J/P_Holdtime之后过期，除非它稍后通过接收新的加入/删除来刷新。
The value of J/P_Holdtime is 210 seconds. This value is based on Section 4.11 of [RFC4601], which says that J/P_HoldTime should be 3.5 * t_periodic where the default for t_periodic is 60 seconds.
J/P_保持时间的值为210秒。该值基于[RFC4601]第4.11节，该节规定J/P_保持时间应为3.5*t_周期，其中t_周期的默认值为60秒。
There may be situations where an administrator decides to stop using PORT. If PORT is disabled on a router interface, or a previously PORT-enabled neighbor no longer announces any of the PORT Hello Options, the router follows the rules in Section 4.3 for taking down connections and starting timers. Next, the router SHOULD trigger a full state update similar to what would be done if the GenID changed in Datagram mode. The router SHOULD send Join/Prune messages for any state where the router switched from PORT to Datagram mode for the upstream neighbor.
可能存在管理员决定停止使用端口的情况。如果路由器接口上的端口被禁用，或者以前启用端口的邻居不再宣布任何端口Hello选项，则路由器将遵循第4.3节中关于断开连接和启动计时器的规则。接下来，路由器应该触发一个完整的状态更新，类似于GenID在数据报模式下更改时所做的操作。对于路由器从端口切换到上游邻居的数据报模式的任何状态，路由器都应发送加入/删减消息。
Transport connections could be established when they are needed or when a router interface to other PIM neighbors has come up. The advantage of on-demand transport connection establishment is the reduction of router resources, especially in the case where there is no need for a full mesh of connections on a network interface. The disadvantage is additional delay and queueing when a Join/Prune message needs to be sent and a transport connection is not established yet.
传输连接可以在需要时建立，或者在路由器接口连接到其他PIM邻居时建立。按需传输连接建立的优点是减少了路由器资源，特别是在网络接口上不需要全网连接的情况下。缺点是，当需要发送加入/删除消息且尚未建立传输连接时，会出现额外的延迟和排队。
If a router interface has become operational and PIM neighbors are learned from Hello messages, at that time, transport connections may be established. The advantage is that a connection is ready to transport data by the time a Join/Prune message needs to be sent. The disadvantage is there can be more connections established than needed. This can occur when there is a small set of RPF neighbors for the active distribution trees compared to the total number of neighbors. Even when transport connections are pre-established before they are needed, a connection can go down and an implementation will have to deal with an on-demand situation.
如果路由器接口已开始运行，并且PIM邻居已从Hello消息中学习，则此时可能会建立传输连接。其优点是，连接在需要发送加入/删除消息时已准备好传输数据。缺点是可以建立比需要更多的连接。当与邻居总数相比，活动分布树的RPF邻居集较少时，可能会发生这种情况。即使在需要之前预先建立了传输连接，连接也可能会中断，实现也必须处理按需情况。
Note that for TCP, it is the router with the lower Connection ID that decides whether to open a connection immediately or on demand. The router with the higher Connection ID SHOULD only initiate a connection on demand, that is, if it needs to send a Join/Prune message and there is no currently established connection.
请注意，对于TCP，具有较低连接ID的路由器决定是立即打开连接还是按需打开连接。具有更高连接ID的路由器应仅在需要时启动连接，也就是说，如果它需要发送加入/删除消息，并且当前没有建立连接。
Therefore, this specification RECOMMENDS but does not mandate the use of on-demand transport connection establishment.
因此，本规范建议但不强制使用按需传输连接建立。
Based on this specification, a transport connection cannot be established until a Hello message is received. Reasons for this are to determine if the PIM neighbor supports this specification and to determine the remote address to use for establishing the transport connection.
根据此规范，在收到Hello消息之前，无法建立传输连接。这样做的原因是为了确定PIM邻居是否支持此规范，以及确定用于建立传输连接的远程地址。
There are cases where it is desirable to suppress entirely the transmission of Hello messages. In this case, how to determine if the PIM neighbor supports this specification and how to determine out-of-band (i.e., outside of the PIM protocol) the remote address for establishing the transport connection are outside the scope of this document. In this case, the following is outside the scope of this document: how to determine if the PIM neighbor supports this specification as well as an out-of-band (outside of the PIM protocol) method to determine the remote address to establish the transport connection.
在某些情况下，希望完全抑制Hello消息的传输。在这种情况下，如何确定PIM邻居是否支持本规范以及如何确定带外（即，在PIM协议之外）用于建立传输连接的远程地址超出了本文档的范围。在这种情况下，以下内容超出了本文档的范围：如何确定PIM邻居是否支持本规范以及带外（PIM协议之外）方法，以确定建立传输连接的远程地址。
To ensure that there is only one TCP connection between a pair of PIM neighbors, the following set of rules MUST be followed. Note that this section applies only to TCP; for SCTP, this is not an issue. Let nodes A and B be two PIM neighbors where A's Connection ID is numerically smaller than B's Connection ID, and each is known to the other as having a potential PIM adjacency relationship.
要确保一对PIM邻居之间只有一个TCP连接，必须遵循以下一组规则。请注意，本节仅适用于TCP；对于SCTP来说，这不是一个问题。假设节点A和B是两个PIM邻居，其中A的连接ID在数值上小于B的连接ID，并且彼此都知道它们具有潜在的PIM邻接关系。
At node A:
在节点A：
o If there is already an established TCP connection to B, on the PIM-over-TCP port, then A MUST NOT attempt to establish a new connection to B. Rather, it uses the established connection to send Join/Prune messages to B. (This is independent of which node initiated the connection.)
o 如果在PIM over TCP端口上已建立到B的TCP连接，则A不得尝试建立到B的新连接。相反，它使用已建立的连接向B发送加入/删除消息（这与启动连接的节点无关）
o If A has initiated a connection to B, but the connection is still in the process of being established, then A MUST refuse any connection on the PIM-over-TCP port from B.
o 如果A已启动与B的连接，但该连接仍在建立过程中，则A必须拒绝B通过TCP端口在PIM上的任何连接。
o At any time when A does not have a connection to B (which is either established or in the process of being established), A MUST accept connections from B.
o 当A没有与B的连接（已建立或正在建立）时，A必须接受B的连接。
At node B:
在节点B：
o If there is already an established TCP connection to A on the PIM-over-TCP port, then B MUST NOT attempt to establish a new connection to A. Rather, it uses the established connection to send Join/Prune messages to A. (This is independent of which node initiated the connection.)
o 如果在PIM over TCP端口上已建立到A的TCP连接，则B不得尝试建立到A的新连接。相反，它使用已建立的连接向A发送加入/删除消息。（这与启动连接的节点无关。）
o If B has initiated a connection to A, but the connection is still in the process of being established, then if A initiates a connection too, B MUST accept the connection initiated by A and release the connection that it (B) initiated.
o 如果B启动了与a的连接，但该连接仍在建立过程中，那么如果a也启动了连接，B必须接受a启动的连接并释放它（B）启动的连接。
For scaling purposes, it may be desirable to allow Join/Prune messages from different PIM protocol families to be sent over the same transport connection. Also, it may be desirable to have a set of Join/Prune messages for one address family sent over a transport connection that is established over a different address-family network layer.
出于扩展目的，可能需要允许通过相同的传输连接发送来自不同PIM协议族的加入/删减消息。此外，可能希望通过在不同地址族网络层上建立的传输连接发送一组用于一个地址族的加入/删减消息。
To be able to do this, we need a common PORT message format. This will provide both record boundary and demux points when sending over a stream protocol like TCP/SCTP.
要做到这一点，我们需要一种通用端口消息格式。当通过流协议（如TCP/SCTP）发送时，这将提供记录边界和解复用点。
A PORT message may contain PORT Options; see Section 5.3. We will define two PORT Options for carrying PIM Join/Prune messages -- one for IPv4 and one for IPv6. For each PIM Join/Prune message to be sent over the transport connection, we send a PORT Join/Prune message containing exactly one such option.
端口消息可能包含端口选项；见第5.3节。我们将定义两个端口选项来承载PIM加入/删除消息——一个用于IPv4，另一个用于IPv6。对于通过传输连接发送的每个PIM加入/删减消息，我们发送一个端口加入/删减消息，其中正好包含一个这样的选项。
Each PORT message will have the Type/Length/Value format. Multiple different TLV types can be sent over the same transport connection.
每个端口消息将具有类型/长度/值格式。可以通过同一传输连接发送多个不同的TLV类型。
To make sure PIM Join/Prune messages are delivered as soon as the TCP transport layer receives the Join/Prune buffer, the TCP Push flag will be set in all outgoing Join/Prune messages sent over a TCP transport connection.
为了确保在TCP传输层接收到Join/Prune缓冲区后立即传递PIM Join/Prune消息，将在通过TCP传输连接发送的所有传出Join/Prune消息中设置TCP Push标志。
PORT messages will be sent using destination TCP port number 8471. When using SCTP as the reliable transport, destination port number 8471 will be used. See Section 12 for IANA considerations.
端口消息将使用目标TCP端口号8471发送。当使用SCTP作为可靠传输时，将使用目标端口号8471。IANA注意事项见第12节。
PORT messages are error checked. This includes unknown/illegal type fields or a truncated message. If the PORT message contains a PIM Join/Prune Message, then that is subject to the normal PIM error
对端口消息进行错误检查。这包括未知/非法类型字段或截断的消息。如果端口消息包含PIM Join/Prune消息，则会出现正常的PIM错误
checks, including checksum verification. If any parsing errors occur in a PORT message, it is skipped, and we proceed to any following PORT messages.
检查，包括校验和验证。如果端口消息中出现任何解析错误，将跳过该消息，然后继续处理以下任何端口消息。
When an unknown type field is encountered, that message MUST be ignored. As specified above, one then proceeds as usual when processing further PORT messages. This is important in order to allow new message types to be specified in the future, without breaking existing implementations. However, if only unknown or invalid messages are received for a longer period of time, an implementation MAY alert the operator. For example, if a message is sent with a wrong length, the receiver is likely to see only unknown/ invalid messages thereafter.
遇到未知类型字段时，必须忽略该消息。如上所述，在处理进一步的端口消息时，将照常进行。为了允许将来指定新的消息类型，而不破坏现有的实现，这一点很重要。但是，如果在较长时间内仅收到未知或无效消息，则实施可能会向操作员发出警报。例如，如果以错误的长度发送消息，则接收方很可能在此后只看到未知/无效消息。
The checksum of the PIM Join/Prune message MUST be calculated exactly as specified in Section 4.9 of [RFC4601]. For IPv6, [RFC4601] specifies the use of a pseudo-header. For PORT, the exact same pseudo-header MUST be used, but its source and destination address fields MUST be set to 0 when calculating the checksum.
PIM Join/Prune消息的校验和必须按照[RFC4601]第4.9节的规定准确计算。对于IPv6，[RFC4601]指定使用伪报头。对于端口，必须使用完全相同的伪标头，但在计算校验和时，其源和目标地址字段必须设置为0。
The TLV type field is 16 bits. The range 65532 - 65535 is for experimental use [RFC3692].
TLV类型字段为16位。范围65532-65535用于实验用途[RFC3692]。
This document defines two message types.
本文档定义了两种消息类型。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface |
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface |
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PORT Join/Prune Message
端口加入/删除消息
The PORT Join/Prune Message is used for sending a PIM Join/Prune.
PORT Join/Prune消息用于发送PIM Join/Prune。
Message Length: Length in bytes for the value part of the Type/ Length/Value encoding. If no PORT Options are included, the length is 12. If n PORT Options with Option Value lengths L1, L2, ..., Ln are included, the message length is 12 + 4*n + L1 + L2 + ... + Ln.
消息长度：类型/长度/值编码的值部分的长度（字节）。如果不包括端口选项，则长度为12。如果包含选项值长度为L1、L2、…、Ln的n个端口选项，则消息长度为12+4*n+L1+L2+…+自然对数。
Reserved: Set to zero on transmission and ignored on receipt.
保留：传输时设置为零，接收时忽略。
Interface ID: This MUST be the Interface ID of the Interface ID Hello Option contained in the PIM Hello messages that the PIM router is sending to the PIM neighbor. It indicates to the PIM neighbor what interface to associate the Join/Prune with. The Interface ID allows us to do connection sharing.
接口ID：这必须是PIM路由器发送给PIM邻居的PIM Hello消息中包含的接口ID Hello选项的接口ID。它向PIM邻居指示要将加入/删除与哪个接口关联。接口ID允许我们进行连接共享。
PORT Options: The message MUST contain exactly one PIM Join/Prune PORT Option, either one PIM IPv4 Join/Prune or one PIM IPv6 Join/ Prune. It MUST NOT contain both. It MAY contain additional options not defined in this document. The behavior when receiving a message containing unknown options depends on the option type. See Section 5.3 for option definitions.
端口选项：消息必须正好包含一个PIM加入/删除端口选项，一个PIM IPv4加入/删除或一个PIM IPv6加入/删除。它不能同时包含两者。它可能包含本文档中未定义的其他选项。接收包含未知选项的消息时的行为取决于选项类型。选项定义见第5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | PORT Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | PORT Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PORT Keep-Alive Message
端口保持活动消息
The PORT Keep-alive Message is used to regularly send PORT messages to verify that a connection is alive. They are used when other PORT messages are not sent at the desired frequency.
端口保持活动消息用于定期发送端口消息，以验证连接是否处于活动状态。当其他端口消息未按所需频率发送时，将使用它们。
Message Length: Length in bytes for the value part of the Type/ Length/Value encoding. If no PORT Options are included, the length is 6. If n PORT Options with Option Value lengths L1, L2, ..., Ln are included, the message length is 6 + 4*n + L1 + L2 + ... + Ln.
消息长度：类型/长度/值编码的值部分的长度（字节）。如果不包括端口选项，则长度为6。如果包含选项值长度为L1、L2、…、Ln的n个端口选项，则消息长度为6+4*n+L1+L2+…+自然对数。
Reserved: Set to zero on transmission and ignored on receipt.
保留：传输时设置为零，接收时忽略。
Holdtime: This specifies a Holdtime in seconds for the connection. A non-zero value means that the connection SHOULD be gracefully shut down if no further PORT messages are received within the specified time. This is measured on the receiving side by measuring the time from when one PORT message has been processed until the next has been processed. Note that this MUST be done for any PORT message, not just keep-alive messages. A Holdtime of 0 disables the keep-alive mechanism.
保持时间：指定连接的保持时间（以秒为单位）。非零值表示如果在指定时间内没有收到更多端口消息，则应正常关闭连接。这在接收端通过测量从处理一个端口消息到处理下一个端口消息的时间来测量。请注意，必须对任何端口消息执行此操作，而不仅仅是保持活动消息。保持时间为0将禁用保持活动机制。
PORT Options: A keep-alive message MUST NOT contain any of the options defined in this document. It MAY contain other options not defined in this document. The behavior when receiving a message containing unknown options depends on the option type. See Section 5.3 for option definitions.
端口选项：保持活动状态消息不得包含此文档中定义的任何选项。它可能包含本文档中未定义的其他选项。接收包含未知选项的消息时的行为取决于选项类型。选项定义见第5.3节。
Each PORT Option is a TLV. The type is 16 bits. The PORT Option type space is split in two ranges. The types in the range 0 - 32767 (the most significant bit is not set) are for Critical Options. The types in the range 32768 - 65535 (the most significant bit is set) are for Non-Critical Options.
每个端口选项都是一个TLV。类型为16位。端口选项类型空间分为两个范围。0-32767范围内的类型（未设置最高有效位）用于关键选项。范围为32768-65535（设置了最高有效位）的类型用于非关键选项。
The behavior of a router receiving a message with an unknown PORT Option is determined by whether the option is a Critical Option. If the message contains an unknown Critical Option, the entire message must be ignored. If the option is Non-Critical, only that particular option is ignored, and the message is processed as if the option was not present.
路由器接收具有未知端口选项的消息的行为取决于该选项是否为关键选项。如果消息包含未知的关键选项，则必须忽略整个消息。如果该选项为非关键选项，则仅忽略该特定选项，并将消息视为该选项不存在而进行处理。
PORT Option types are assigned by IANA, except the ranges 32764 - 32767 and 65532 - 65535, which are for experimental use [RFC3692]. The length specifies the length of the value in bytes. Below are the two options defined in this document.
端口选项类型由IANA分配，但范围32764-32767和65532-65535除外，这两个范围仅供实验使用[RFC3692]。长度以字节为单位指定值的长度。以下是本文件中定义的两个选项。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type = 1 | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 Join/Prune Message |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type = 1 | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 Join/Prune Message |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM IPv4 Join/Prune Option Format
PIM IPv4加入/删除选项格式
The IPv4 Join/Prune Option is used to carry a PIMv2 Join/Prune message that has all IPv4-encoded addresses in the PIM payload.
IPv4加入/删减选项用于携带PIMv2加入/删减消息，该消息在PIM有效负载中包含所有IPv4编码的地址。
Option Value Length: The number of bytes that make up the PIMv2 Join/Prune message.
选项值长度：组成PIMv2加入/删除消息的字节数。
PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with no IP header in front of it.
PIMv2加入/删减消息：PIMv2加入/删减消息和负载前面没有IP头。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type = 2 | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 Join/Prune Message |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type = 2 | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 Join/Prune Message |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM IPv6 Join/Prune Option Format
PIM IPv6加入/删除选项格式
The IPv6 Join/Prune Option is used to carry a PIMv2 Join/Prune message that has all IPv6-encoded addresses in the PIM payload.
IPv6加入/删减选项用于携带PIMv2加入/删减消息，该消息在PIM有效负载中包含所有IPv6编码的地址。
Option Value Length: The number of bytes that make up the PIMv2 Join/Prune message.
选项值长度：组成PIMv2加入/删除消息的字节数。
PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with no IP header in front of it.
PIMv2加入/删减消息：PIMv2加入/删减消息和负载前面没有IP头。
When explicit tracking is used, a router keeps track of Join state for individual downstream neighbors on a given interface. This MUST be done for all PORT Joins and Prunes. Note that it may also be done for native Join/Prune messages, if all neighbors on the LAN have set the T bit of the LAN Prune Delay Option (see definition in Section 4.9.2 of [RFC4601]). The discussion below covers ET (explicit tracking) neighbors and non-ET neighbors. The set of ET neighbors MUST include the PORT neighbors. The set of non-ET neighbors consists of all the non-PORT neighbors, unless all neighbors have set the LAN Prune Delay T bit -- in which case, the ET neighbors set contains all neighbors.
当使用显式跟踪时，路由器跟踪给定接口上各个下游邻居的连接状态。必须对所有端口联接和修剪执行此操作。请注意，如果LAN上的所有邻居都设置了LAN修剪延迟选项的T位（参见[RFC4601]第4.9.2节中的定义），则也可以对本机加入/修剪消息执行此操作。下面的讨论涉及ET（显式跟踪）邻居和非ET邻居。ET邻居集必须包括端口邻居。非ET邻居集由所有非端口邻居组成，除非所有邻居都设置了LAN修剪延迟T位——在这种情况下，ET邻居集包含所有邻居。
For some link-types, e.g., point-to-point, tracking neighbors is no different than tracking interfaces. It may also be possible for an implementation to treat different downstream neighbors as being on different logical interfaces, even if they are on the same physical link. Exactly how this is implemented, and for which link types, is left to the implementer.
对于某些链路类型，例如点对点，跟踪邻居与跟踪接口没有什么不同。实现也可能将不同的下游邻居视为位于不同的逻辑接口上，即使它们位于同一物理链路上。具体实现方式以及链接类型由实现者决定。
For (*,G) and (S,G) state, the router starts forwarding traffic on an interface when a Join is received from a neighbor on such an interface. When a non-ET neighbor sends a Prune, as specified in [RFC4601], if no Join is sent to override this Prune before the expiration of the Override Timer, the upstream router concludes that no non-ET neighbor is interested. If no ET neighbors are interested, the interface can be removed from the oif-list. When an ET neighbor sends a Prune, one removes the Join state for that neighbor. If no other ET or non-ET neighbors are interested, the interface can be removed from the oif-list. When a PORT neighbor sends a Prune, there can be no Prune Override, since the Prune is not visible to other neighbors.
对于（*，G）和（S，G）状态，当从接口上的邻居接收到加入时，路由器开始在接口上转发通信量。如[RFC4601]中所述，当非ET邻居发送修剪时，如果在覆盖计时器到期之前没有发送连接来覆盖此修剪，则上游路由器得出结论认为没有非ET邻居感兴趣。如果没有ET邻居感兴趣，则可以从oif列表中删除该接口。当ET邻居发送剪枝时，会删除该邻居的连接状态。如果没有其他ET或非ET邻居感兴趣，则可以从oif列表中删除该接口。当端口邻居发送剪枝时，不能有剪枝覆盖，因为剪枝对其他邻居不可见。
For (S,G,rpt) state, the router needs to track Prune state on the shared tree. It needs to know which ET neighbors have sent Prunes, and whether any non-ET neighbors have sent Prunes. Normally, one would forward a packet from a source S to a group G out on an interface if a (*,G) Join is received, but no (S,G,rpt) Prune. With ET, one needs to do this check per ET neighbor. That is, the packet should be forwarded except in two cases: all ET neighbors that have sent (*,G) Joins have also sent (S,G,rpt) Prunes, and if a non-ET neighbor has sent a (*,G) Join, whether there also is non-ET (S,G,rpt) Prune state.
对于（S、G、rpt）状态，路由器需要跟踪共享树上的修剪状态。它需要知道哪些ET邻居发送了修剪，以及是否有任何非ET邻居发送了修剪。通常，如果接收到（*，G）连接，则会将数据包从源S转发到接口上的组G out，但不会进行（S，G，rpt）删减。对于ET，需要对每个ET邻居执行此检查。也就是说，除了两种情况外，应该转发数据包：所有发送（*，G）连接的ET邻居也发送了（S，G，rpt）修剪，如果非ET邻居发送了（*，G）连接，则是否也存在非ET（S，G，rpt）修剪状态。
To allow for efficient use of router resources, one can mux Join/ Prune messages of different address families on the same transport connection. There are two ways this can be accomplished -- using a common message format over a TCP connection or using multiple streams over a single SCTP connection.
为了有效利用路由器资源，可以对同一传输连接上不同地址族的消息进行mux连接/删减。有两种方法可以实现这一点——通过TCP连接使用公共消息格式，或者通过单个SCTP连接使用多个流。
Using the common message format described in this specification, and using different PORT Options, both IPv4- and IPv6-based Join/Prune messages can be encoded within the same transport connection.
使用本规范中描述的通用消息格式，并使用不同的端口选项，可以在同一传输连接中对基于IPv4和IPv6的加入/删除消息进行编码。
When using SCTP multi-streaming, the common message format is still used to convey address-family information, but an SCTP association is used, on a per-family basis, to send data concurrently for multiple families. When data is sent concurrently, head-of-line blocking (which can occur when using TCP) is avoided.
在使用SCTP多流传输时，仍然使用通用消息格式来传递地址族信息，但在每个族的基础上，使用SCTP关联来并发发送多个族的数据。当同时发送数据时，避免了行首阻塞（使用TCP时可能发生）。
There are no changes to processing of other PIM messages like PIM Asserts, Grafts, Graft-Acks, Registers, and Register-Stops. This goes for Bootstrap Router (BSR) and Auto-RP type messages as well.
对其他PIM消息（如PIM断言、嫁接、嫁接确认、寄存器和寄存器停止）的处理没有任何更改。这也适用于引导路由器（BSR）和自动RP类型的消息。
This extension is applicable only to PIM-SM, PIM-SSM, and Bidirectional PIM. It does not take requirements for PIM Dense Mode (PIM-DM) into consideration.
此扩展仅适用于PIM-SM、PIM-SSM和双向PIM。它不考虑PIM密集模式（PIM-DM）的要求。
As noted in the introduction, this is an experimental extension to PIM, and using reliable delivery for PIM messages is a new concept. There are several potential transport-related concerns. Hopefully, experiences from early implementations and deployments will reveal what concerns are relevant and how to resolve them.
如引言中所述，这是PIM的一个实验性扩展，对PIM消息使用可靠传递是一个新概念。有几个潜在的运输相关问题。希望早期实施和部署的经验能够揭示哪些问题是相关的，以及如何解决这些问题。
One consideration is keep-alive mechanisms. We have defined an optional keep-alive mechanism for PORT; see Section 4.2. Also, SCTP and many TCP implementations provide keep-alive mechanisms that could be used. When to use keep-alive messages and which mechanism to use are unclear; however, we believe the PORT Keep-alive allows for better application control. It is unclear what Holdtimes are preferred for the PORT Keep-alives. For now, it is RECOMMENDED that administrators be able to configure whether to use keep-alives, what Holdtimes to use, etc.
一个考虑因素是保持活力的机制。我们为端口定义了可选的保持活动机制；见第4.2节。此外，SCTP和许多TCP实现提供了可以使用的保持活动的机制。何时使用保持活动状态消息以及使用何种机制尚不清楚；但是，我们相信端口保持活动允许更好的应用程序控制。目前尚不清楚港口保持活动的最佳保持时间。目前，建议管理员能够配置是否使用keep alives、使用什么保持时间等。
In a stable state, it is expected that only occasional small messages are sent over a PORT connection. This depends on how often PIM Join/ Prune state changes. Thus, over a long period of time, there may be only small messages that never use the entire TCP congestion window, and the window may become very large. This would then be an issue if there is a state change that makes PORT send a very large message. It may be good if the TCP stack provides some rate-limiting or burst-limiting. The congestion control mechanism defined in [RFC3465] may be of help.
在稳定状态下，预期只有偶尔的小消息通过端口连接发送。这取决于PIM连接/删除状态更改的频率。因此，在很长一段时间内，可能只有很少的消息不会使用整个TCP拥塞窗口，并且窗口可能变得非常大。如果有状态更改使端口发送非常大的消息，则这将是一个问题。如果TCP堆栈提供一些速率限制或突发限制，这可能是好的。[RFC3465]中定义的拥塞控制机制可能会有所帮助。
With PORT, it is possible that only occasional small messages are sent (as discussed in the previous paragraph). This may cause problems for the TCP retransmit mechanism. In particular, the TCP Fast Retransmit algorithm may never get triggered. For further discussion of this and a possible solution, see [RFC3042].
对于端口，可能只发送偶尔的小消息（如前一段所述）。这可能会导致TCP重传机制出现问题。特别是，TCP快速重传算法可能永远不会被触发。有关此问题的进一步讨论和可能的解决方案，请参阅[RFC3042]。
There may be SCTP issues similar to the TCP issues discussed in the above two paragraphs.
可能存在与上述两段中讨论的TCP问题类似的SCTP问题。
This document defines using TCP or SCTP transports between pairs of PIM neighbors. It is recommended that this mechanism be disabled by default. An administrator can then enable PORT TCP and/or SCTP on PIM-enabled interfaces. If two neighbors both have PORT SCTP (or both have PORT TCP), they will only use SCTP (or alternatively, TCP) for PIM Join/Prune messages. This is the case even when the connection is down (there is no fallback to native Join/Prune messages).
本文档定义了在成对的PIM邻居之间使用TCP或SCTP传输。建议默认情况下禁用此机制。然后，管理员可以在启用PIM的接口上启用端口TCP和/或SCTP。如果两个邻居都有端口SCTP（或都有端口TCP），则它们将仅对PIM加入/删除消息使用SCTP（或TCP）。即使在连接关闭时也是如此（没有回退到本机加入/删除消息）。
When PORT support is enabled, a router sends PIM Hello messages announcing support for TCP and/or SCTP and also Connection IDs. It should be possible to configure a local Connection ID, and also to see what PORT capabilities and Connection IDs PIM neighbors are announcing. Based on these advertisements, pairs of PIM neighbors will decide whether to try to establish a PORT connection. There should be a way for an operator to check the current connection state. Statistics on the number of PORT messages sent and received (including number of invalid messages) may also be helpful.
启用端口支持时，路由器发送PIM Hello消息，宣布支持TCP和/或SCTP以及连接ID。应该可以配置本地连接ID，还可以查看PIM邻居宣布的端口功能和连接ID。根据这些播发，成对的PIM邻居将决定是否尝试建立端口连接。操作员应该有办法检查当前连接状态。发送和接收的端口消息数（包括无效消息数）的统计信息也可能有用。
For connection security (see Section 4.1), it should be possible to enable a GTSM check to only accept connections (TCP/SCTP packets) when the sender is within a certain number of router hops. Also, one should be able to configure the use of TCP-AO.
对于连接安全性（参见第4.1节），当发送方在一定数量的路由器跃点内时，应该可以启用GTSM检查，以仅接受连接（TCP/SCTP数据包）。此外，还应该能够配置TCP-AO的使用。
For connection maintenance (see Section 4.2), it is recommended to support Keep-Alive messages. It should be configurable whether to send Keep-Alives -- and if doing so, whether to use a Holdtime and what Holdtime to use.
对于连接维护（参见第4.2节），建议支持保持活动消息。它应该可以配置是否发送Keep Alives——如果这样做，是否使用Holdtime以及使用什么Holdtime。
There should be some way to alert an operator when PORT connections are going down or when there is a failure in establishing a PORT connection. Also, information like the number of connection failures, and how long the connection has been up or down, is useful.
当端口连接中断或在建立端口连接时出现故障时，应该有某种方法提醒操作员。此外，诸如连接失败的次数以及连接开启或关闭的时间等信息也很有用。
There are several security issues related to the use of TCP or SCTP transports. By sending packets with a spoofed source address, off-path attackers might establish a connection or inject packets into an existing connection. This might allow an attacker to send spoofed Join/Prune messages and/or reset a connection. Mechanisms that help protect against this are discussed in Section 4.1.
使用TCP或SCTP传输有几个安全问题。通过发送带有伪造源地址的数据包，非路径攻击者可能会建立连接或将数据包注入现有连接。这可能允许攻击者发送伪造的加入/删除消息和/或重置连接。第4.1节讨论了有助于防止这种情况的机制。
For authentication, TCP-AO [RFC5925] may be used with TCP, Authenticated Chunks [RFC4895] may be used with SCTP. Also, GTSM [RFC5082] can be used to help prevent spoofing.
对于身份验证，TCP-AO[RFC5925]可与TCP一起使用，身份验证块[RFC4895]可与SCTP一起使用。此外，GTSM[RFC5082]可用于帮助防止欺骗。
This specification makes use of a TCP port number and an SCTP port number for the use of the pim-port service that has been assigned by IANA. It also makes use of IANA PIM Hello Options assignments that have been made permanent.
本规范使用TCP端口号和SCTP端口号来使用IANA分配的pim端口服务。它还使用IANA PIM Hello选项分配，这些分配已被永久化。
IANA previously had assigned a port number that is used as a destination port for pim-port TCP and SCTP transports. The assigned number is 8471. References to this document have been added to the Service Name and Transport Protocol Port Number Registry for pim-port.
IANA以前分配了一个端口号，用作pim端口TCP和SCTP传输的目标端口。分配的号码是8471。对本文档的引用已添加到pim端口的服务名称和传输协议端口号注册表中。
In the "PIM-Hello Options" registry, the following options have been added for PORT.
在“PIM Hello Options”注册表中，为端口添加了以下选项。
Value Length Name Reference
------- ---------- ----------------------- ---------------
27 Variable PIM-over-TCP-Capable this document
28 Variable PIM-over-SCTP-Capable this document
Value Length Name Reference
------- ---------- ----------------------- ---------------
27 Variable PIM-over-TCP-Capable this document
28 Variable PIM-over-SCTP-Capable this document
A registry for PORT message types has been created. The message type is a 16-bit integer, with values from 0 to 65535. An RFC is required for assignments in the range 0 - 65531. This document defines two PORT message types: Type 1 (Join/Prune) and Type 2 (Keep-alive). The type range 65532 - 65535 is for experimental use [RFC3692].
已创建端口消息类型的注册表。消息类型为16位整数，值从0到65535。0-65531范围内的分配需要RFC。本文档定义了两种端口消息类型：类型1（Join/Prune）和类型2（Keep-alive）。型号范围65532-65535用于实验用途[RFC3692]。
The initial content of the registry is as follows:
登记处的初步内容如下：
Type Name Reference
------------- ------------------------------- ---------------
0 Reserved this document
1 Join/Prune this document
2 Keep-alive this document
3-65531 Unassigned
65532-65535 Experimental this document
Type Name Reference
------------- ------------------------------- ---------------
0 Reserved this document
1 Join/Prune this document
2 Keep-alive this document
3-65531 Unassigned
65532-65535 Experimental this document
A registry for PORT Option types. The option type is a 16-bit integer, with values from 0 to 65535. The type space is split in two ranges, 0 - 32767 for Critical Options and 32768 - 65535 for Non-Critical Options. Option types are assigned by IANA, except the ranges 32764 - 32767 and 65532 - 65535 that are for experimental use [RFC3692]. An RFC is required for the IANA assignments. An RFC defining a new option type must specify whether the option is Critical or Non-Critical in order for IANA to assign a type. This document defines two Critical PORT Option types: Type 1 (PIM IPv4 Join/Prune) and Type 2 (PIM IPv6 Join/Prune).
端口选项类型的注册表。选项类型为16位整数，值从0到65535。类型空间分为两个范围，关键选项为0-32767，非关键选项为32768-65535。选项类型由IANA分配，但用于实验的范围32764-32767和65532-65535除外[RFC3692]。IANA分配需要RFC。定义新选项类型的RFC必须指定该选项是关键的还是非关键的，以便IANA分配类型。本文档定义了两种关键端口选项类型：类型1（PIM IPv4加入/删除）和类型2（PIM IPv6加入/删除）。
The initial content of the registry is as follows:
登记处的初步内容如下：
Type Name Reference
------------- ---------------------------------- ---------------
0 Reserved this document
1 PIM IPv4 Join/Prune this document
2 PIM IPv6 Join/Prune this document
3-32763 Unassigned Critical Options
32764-32767 Experimental this document
32768-65531 Unassigned Non-Critical Options
65532-65535 Experimental this document
Type Name Reference
------------- ---------------------------------- ---------------
0 Reserved this document
1 PIM IPv4 Join/Prune this document
2 PIM IPv6 Join/Prune this document
3-32763 Unassigned Critical Options
32764-32767 Experimental this document
32768-65531 Unassigned Non-Critical Options
65532-65535 Experimental this document
In addition to the persons listed as authors, significant contributions were provided by Apoorva Karan and Arjen Boers.
除了被列为作者的人之外，Apoorva Karan和Arjen Boers也做出了重要贡献。
The authors would like to give a special thank you and appreciation to Nidhi Bhaskar for her initial design and early prototype of this idea.
作者要特别感谢Nidhi Bhaskar，感谢她最初的设计和这个想法的早期原型。
Appreciation goes to Randall Stewart for his authoritative review and recommendation for using SCTP.
感谢Randall Stewart对使用SCTP的权威性评论和建议。
Thanks also goes to the following for their ideas and review of this specification: Mike McBride, Toerless Eckert, Yiqun Cai, Albert Tian, Suresh Boddapati, Nataraj Batchu, Daniel Voce, John Zwiebel, Yakov Rekhter, Lenny Giuliano, Gorry Fairhurst, Sameer Gulrajani, Thomas Morin, Dimitri Papadimitriou, Bharat Joshi, Rishabh Parekh, Manav Bhatia, Pekka Savola, Tom Petch, and Joe Touch.
还感谢以下人员对本规范的想法和评论：迈克·麦克布莱德、托利斯·埃克特、蔡益群、阿尔伯特·田、苏雷什·博达帕蒂、纳塔拉吉·巴楚、丹尼尔·沃奇、约翰·兹维贝尔、雅科夫·雷克特、伦尼·朱利亚诺、戈里·费尔赫斯特、萨米尔·古拉贾尼、托马斯·莫林、迪米特里·帕帕迪米特里、巴拉特·乔希、里沙布·帕雷克、马纳夫·巴蒂亚，佩卡·萨沃拉、汤姆·佩奇和乔·图奇。
A special thank you goes to Eric Rosen for his very detailed review and commentary. Many of his comments are reflected as text in this specification.
特别感谢埃里克·罗森的详细评论和评论。他的许多评论在本规范中以文本形式反映出来。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[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月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895]Tuexen，M.，Stewart，R.，Lei，P.，和E.Rescorla，“流控制传输协议（SCTP）的认证块”，RFC 48952007年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) Hello Option for PIM", RFC 6395, October 2011.
[RFC6395]Gullajani，S.和S.Venaas，“PIM的接口标识符（ID）Hello选项”，RFC 63952011年10月。
[AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/ address-family-numbers>.
[AFI]IANA，“地址家庭编号”<http://www.iana.org/assignments/ 地址系列号>。
[HELLO-OPT] IANA, "PIM-Hello Options", <http://www.iana.org/assignments/pim-parameters>.
[HELLO-OPT]IANA，“PIM HELLO选项”<http://www.iana.org/assignments/pim-parameters>.
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]Allman，M.，Balakrishnan，H.，和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]Allman，M.，“具有适当字节计数的TCP拥塞控制（ABC）”，RFC 3465，2003年2月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
Authors' Addresses
作者地址
Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道迪诺·法里纳奇思科系统公司，邮编95134
EMail: dino@cisco.com
EMail: dino@cisco.com
IJsbrand Wijnands Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道IJsbrand Wijnands思科系统公司，邮编95134
EMail: ice@cisco.com
EMail: ice@cisco.com
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道Stig Venaas思科系统公司，邮编95134
EMail: stig@cisco.com
EMail: stig@cisco.com
Maria Napierala AT&T Labs 200 Laurel Drive Middletown, New Jersey 07748 USA
美国新泽西州米德尔顿劳雷尔大道200号玛丽亚·纳皮拉拉AT&T实验室，邮编：07748
EMail: mnapierala@att.com
EMail: mnapierala@att.com