summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6559.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6559.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6559.txt')
-rw-r--r--doc/rfc/rfc6559.txt1627
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc6559.txt b/doc/rfc/rfc6559.txt
new file mode 100644
index 0000000..27c12bf
--- /dev/null
+++ b/doc/rfc/rfc6559.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+ 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.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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
+
+
+
+Farinacci, et al. Experimental [Page 1]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+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
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 2]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+1. Introduction
+
+ 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 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.
+
+ The explicit non-goals of this specification are:
+
+ o Making changes to the PIM message formats as defined in [RFC4601].
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+Farinacci, et al. Experimental [Page 3]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+1.1. Requirements Notation
+
+ 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].
+
+1.2. Definitions
+
+ 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.
+
+ 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.
+
+ PORT Join/Prune message: A Join/Prune message using TCP or SCTP for
+ transport.
+
+ Datagram Mode: The procedures whereby PIM encapsulates triggered or
+ periodic Join/Prune messages in IP packets.
+
+ PORT Mode: The procedures used by PIM and defined in this
+ specification for sending Join/Prune messages over the TCP or SCTP
+ transport layer.
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 4]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+2. Protocol Overview
+
+ 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.
+
+ PORT only applies to PIM Sparse-Mode [RFC4601] and Bidirectional PIM
+ [RFC5015] Join/Prune messages.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Farinacci, et al. Experimental [Page 5]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+3. PIM Hello Options
+
+3.1. PIM over the TCP Transport Protocol
+
+ Option Type: PIM-over-TCP-Capable
+
+ 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].
+
+ 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.
+
+ All Hello messages containing the PIM-over-TCP-Capable Hello Option
+ MUST also contain the Interface ID Hello Option, see Section 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.
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 6]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+3.2. PIM over the SCTP Transport Protocol
+
+ Option Type: PIM-over-SCTP-Capable
+
+ 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].
+
+ 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.
+
+ All Hello messages containing the PIM-over-SCTP-Capable Hello Option
+ MUST also contain the Interface ID Hello Option; see Section 3.3.
+
+ Implementations MAY provide a configuration option to enable or
+ disable PORT functionality. It is RECOMMENDED that this capability
+ be disabled by default.
+
+
+
+
+Farinacci, et al. Experimental [Page 7]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+3.3. Interface ID
+
+ All Hello messages containing PIM-over-TCP-Capable or PIM-over-SCTP-
+ Capable Hello Options MUST also contain the Interface ID Hello Option
+ [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.
+
+ 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].
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 8]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+4. Establishing Transport Connections
+
+ 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.
+
+ 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.
+
+ 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.
+
+ When the router is using SCTP, the IP address comparison need not be
+ done since the SCTP protocol can handle call collision.
+
+ 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.
+
+
+
+
+
+Farinacci, et al. Experimental [Page 9]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Farinacci, et al. Experimental [Page 10]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ 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.
+
+4.1. Connection Security
+
+ 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.
+
+ Implementations SHOULD support the TCP Authentication Option (TCP-AO)
+ [RFC5925] and SCTP Authenticated Chunks [RFC4895].
+
+4.2. Connection Maintenance
+
+ 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.
+
+
+
+Farinacci, et al. Experimental [Page 11]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+
+Farinacci, et al. Experimental [Page 12]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ 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.
+
+4.3. Actions When a Connection Goes Down
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 13]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+4.4. Moving from PORT to Datagram Mode
+
+ 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.
+
+4.5. On-Demand versus Pre-Configured Connections
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Therefore, this specification RECOMMENDS but does not mandate the use
+ of on-demand transport connection establishment.
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 14]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+4.6. Possible Hello Suppression Considerations
+
+ 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.
+
+ 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.
+
+4.7. Avoiding a Pair of TCP Connections between Neighbors
+
+ 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.
+
+ At node 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 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 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.
+
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 15]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ At node 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 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.
+
+5. PORT Message Definitions
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Each PORT message will have the Type/Length/Value format. Multiple
+ different TLV types can be sent over the same transport connection.
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+
+Farinacci, et al. Experimental [Page 16]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ The TLV type field is 16 bits. The range 65532 - 65535 is for
+ experimental use [RFC3692].
+
+ This document defines two message types.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 17]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+5.1. PORT 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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.
+
+ 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.
+
+ 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.
+
+
+
+Farinacci, et al. Experimental [Page 18]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+5.2. PORT Keep-Alive 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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.
+
+ Reserved: Set to zero on transmission and ignored on receipt.
+
+
+
+Farinacci, et al. Experimental [Page 19]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ 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. PORT Options
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 20]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+5.3.1. PIM IPv4 Join/Prune Option
+
+ 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
+
+ The IPv4 Join/Prune Option is used to carry a PIMv2 Join/Prune
+ message that has all IPv4-encoded addresses in the PIM payload.
+
+ Option Value Length: The number of bytes that make up the PIMv2
+ Join/Prune message.
+
+ PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with
+ no IP header in front of it.
+
+5.3.2. PIM IPv6 Join/Prune Option
+
+ 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
+
+ The IPv6 Join/Prune Option is used to carry a PIMv2 Join/Prune
+ message that has all IPv6-encoded addresses in the PIM payload.
+
+ Option Value Length: The number of bytes that make up the PIMv2
+ Join/Prune message.
+
+ PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with
+ no IP header in front of it.
+
+
+
+
+Farinacci, et al. Experimental [Page 21]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+6. Explicit Tracking
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 22]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+7. Support of Multiple Address Families
+
+ 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.
+
+ 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.
+
+ 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.
+
+8. Miscellany
+
+ 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.
+
+ 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.
+
+9. Transport Considerations
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 23]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ 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].
+
+ There may be SCTP issues similar to the TCP issues discussed in the
+ above two paragraphs.
+
+10. Manageability Considerations
+
+ 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).
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 24]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ 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.
+
+ 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.
+
+11. Security Considerations
+
+ 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.
+
+ 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.
+
+12. IANA Considerations
+
+ 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.
+
+12.1. PORT Port Number
+
+ 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.
+
+12.2. PORT Hello Options
+
+ In the "PIM-Hello Options" registry, the following options have been
+ added for PORT.
+
+ Value Length Name Reference
+ ------- ---------- ----------------------- ---------------
+ 27 Variable PIM-over-TCP-Capable this document
+ 28 Variable PIM-over-SCTP-Capable this document
+
+
+
+
+Farinacci, et al. Experimental [Page 25]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+12.3. PORT Message Type Registry
+
+ 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].
+
+ 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
+
+12.4. PORT Option Type Registry
+
+ 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).
+
+ 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
+
+13. Contributors
+
+ In addition to the persons listed as authors, significant
+ contributions were provided by Apoorva Karan and Arjen Boers.
+
+
+
+
+Farinacci, et al. Experimental [Page 26]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+14. Acknowledgments
+
+ 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.
+
+ Appreciation goes to Randall Stewart for his authoritative review and
+ recommendation for using 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.
+
+15. References
+
+15.1. Normative References
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+ "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+ Protocol Specification (Revised)", RFC 4601,
+ August 2006.
+
+ [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
+ "Authenticated Chunks for the Stream Control
+ Transmission Protocol (SCTP)", RFC 4895, August 2007.
+
+ [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
+ RFC 4960, September 2007.
+
+ [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L.
+ Vicisano, "Bidirectional Protocol Independent Multicast
+ (BIDIR-PIM)", RFC 5015, October 2007.
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 27]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+ [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
+ Pignataro, "The Generalized TTL Security Mechanism
+ (GTSM)", RFC 5082, October 2007.
+
+ [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
+ Authentication Option", RFC 5925, June 2010.
+
+ [RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier
+ (ID) Hello Option for PIM", RFC 6395, October 2011.
+
+15.2. Informative References
+
+ [AFI] IANA, "Address Family Numbers",
+ <http://www.iana.org/assignments/
+ address-family-numbers>.
+
+ [HELLO-OPT] IANA, "PIM-Hello Options",
+ <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.
+
+ [RFC3465] Allman, M., "TCP Congestion Control with Appropriate
+ Byte Counting (ABC)", RFC 3465, February 2003.
+
+ [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
+ Considered Useful", BCP 82, RFC 3692, January 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 28]
+
+RFC 6559 A Reliable Transport Mechanism for PIM March 2012
+
+
+Authors' Addresses
+
+ Dino Farinacci
+ Cisco Systems
+ Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: dino@cisco.com
+
+
+ IJsbrand Wijnands
+ Cisco Systems
+ Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: ice@cisco.com
+
+
+ Stig Venaas
+ Cisco Systems
+ Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: stig@cisco.com
+
+
+ Maria Napierala
+ AT&T Labs
+ 200 Laurel Drive
+ Middletown, New Jersey 07748
+ USA
+
+ EMail: mnapierala@att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Experimental [Page 29]
+