draft-ietf-pim-port-04.txt   draft-ietf-pim-port-05.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft IJ. Wijnands Internet-Draft IJ. Wijnands
Intended status: Experimental S. Venaas Intended status: Experimental S. Venaas
Expires: April 28, 2011 cisco Systems Expires: August 19, 2011 cisco Systems
M. Napierala M. Napierala
AT&T Labs AT&T Labs
October 25, 2010 February 15, 2011
A Reliable Transport Mechanism for PIM A Reliable Transport Mechanism for PIM
draft-ietf-pim-port-04.txt draft-ietf-pim-port-05.txt
Abstract Abstract
This draft describes how a reliable transport mechanism can be used This draft describes how a reliable transport mechanism can be used
by the PIM protocol to optimize CPU and bandwidth resource by the PIM protocol to optimize CPU and bandwidth resource
utilization by eliminating periodic Join/Prune message transmission. utilization by eliminating periodic Join/Prune message transmission.
This draft proposes a modular extension to PIM to use either the TCP This draft proposes a modular extension to PIM to use either the TCP
or SCTP transport protocol. or SCTP transport protocol.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on August 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3. New PIM Hello Options . . . . . . . . . . . . . . . . . . . . 8 3. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . 8
3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 8 3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 8
3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 9 3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 9
3.3. Interface ID . . . . . . . . . . . . . . . . . . . . . . . 10
4. Establishing Transport Connections . . . . . . . . . . . . . . 11 4. Establishing Transport Connections . . . . . . . . . . . . . . 11
4.1. TCP Connection Maintenance . . . . . . . . . . . . . . . . 12 4.1. Connection Security . . . . . . . . . . . . . . . . . . . 12
4.2. Moving from PORT to Datagram Mode . . . . . . . . . . . . 13 4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 13
4.3. On-demand versus Pre-configured Connections . . . . . . . 14 4.3. Actions When a Connection Goes Down . . . . . . . . . . . 14
4.4. Possible Hello Suppression Considerations . . . . . . . . 14 4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 15
4.5. Avoiding a Pair of Connections between Neighbors . . . . . 15 4.5. On-demand versus Pre-configured Connections . . . . . . . 15
5. Common Header Definition . . . . . . . . . . . . . . . . . . . 16 4.6. Possible Hello Suppression Considerations . . . . . . . . 16
6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 20 4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 16
7. Multiple Instances and Address-Family Support . . . . . . . . 21 5. PORT Message Definition . . . . . . . . . . . . . . . . . . . 18
8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5.2. PORT Keep-alive Message . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 21
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 7. Multiple Address-Family Support . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. PORT Message Type Registry . . . . . . . . . . . . . . . . 27
10.2. PORT Option Type Registry . . . . . . . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The goals of this specification are: The goals of this specification are:
o To create a simple incremental mechanism to provide reliable PIM o To create a simple incremental mechanism to provide reliable PIM
message delivery in PIM version 2 for use with PIM Sparse-Mode message delivery in PIM version 2 for use with PIM Sparse-Mode
[RFC4601] (including Source-Specific Multicast) and Bidirectional [RFC4601] (including Source-Specific Multicast) and Bidirectional
PIM [RFC5015]. PIM [RFC5015].
skipping to change at page 3, line 25 skipping to change at page 3, line 25
message transmission only. message transmission only.
o When a router supports this specification, it need not use the o When a router supports this specification, it need not use the
reliable transport mechanism with every neighbor. That is, reliable transport mechanism with every neighbor. That is,
negotiation on a per neighbor basis will occur. negotiation on a per neighbor basis will occur.
The explicit non-goals of this specification are: The explicit non-goals of this specification are:
o Changes to the PIM message formats as defined in [RFC4601]. o Changes to the PIM message formats as defined in [RFC4601].
o Provide support for automatic switching between Datagram mode and o Provide support for automatic switching between the reliable
Transport mode. Two routers that are PIM neighbors on a link will transport mechanism and the regular PIM mechanism defined in
always use Transport mode if and only if both have Transport mode [RFC4601]. Two routers that are PIM neighbors on a link will
enabled. always use the reliable transport mechanism if and only if both
have reliable transport enabled.
This document will specify how periodic Join/Prune message This document will specify how periodic Join/Prune message
transmission can be eliminated by using TCP [RFC0793] or SCTP transmission can be eliminated by using TCP [RFC0793] or SCTP
[RFC4960] as the reliable transport mechanism for Join/Prune [RFC4960] as the reliable transport mechanism for Join/Prune
messages. messages.
This specification enables greater scalability in terms of control This specification enables greater scalability in terms of control
traffic overhead. However, for routers connected to multi-access traffic overhead. However, for routers connected to multi-access
links that comes at the price of increased control plane state links that comes at the price of increased control plane state
overhead and the control plane overhead required to maintain this overhead and the control plane overhead required to maintain this
skipping to change at page 4, line 4 skipping to change at page 4, line 5
interference, and other impairments can result in temporary spikes in interference, and other impairments can result in temporary spikes in
the packet loss. In these environments, periodic PIM joining can the packet loss. In these environments, periodic PIM joining can
cause join latency when messages are lost causing a retransmission cause join latency when messages are lost causing a retransmission
only 60 seconds later. By applying a reliable transport, a lost join only 60 seconds later. By applying a reliable transport, a lost join
is retransmitted rapidly. Furthermore, when the last user leaves a is retransmitted rapidly. Furthermore, when the last user leaves a
multicast group, any lost prune is similarly repaired and the multicast group, any lost prune is similarly repaired and the
multicast stream is quickly removed from the wireless/satellite link. multicast stream is quickly removed from the wireless/satellite link.
Without a reliable transport, the multicast transmission could Without a reliable transport, the multicast transmission could
otherwise continue until it timed out, roughly 3 minutes later. As otherwise continue until it timed out, roughly 3 minutes later. As
network resources are at a premium in many of these environments, network resources are at a premium in many of these environments,
rapid termination of the multicast stream is critical to maintaining rapid termination of the multicast stream is critical for maintaining
efficient use of bandwidth. efficient use of bandwidth.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Definitions 1.2. Definitions
skipping to change at page 6, line 30 skipping to change at page 6, line 30
PORT can be incrementally used on a link between PORT capable PORT can be incrementally used on a link between PORT capable
neighbors. Routers which are not PORT capable can continue to use neighbors. Routers which are not PORT capable can continue to use
PIM in Datagram Mode. PORT capability is detected using new PORT PIM in Datagram Mode. PORT capability is detected using new PORT
Capable PIM Hello Options. Capable PIM Hello Options.
Once PORT is enabled on an interface and a PIM neighbor also Once PORT is enabled on an interface and a PIM neighbor also
announces that it is PORT enabled, only PORT Join/Prune messages will announces that it is PORT enabled, only PORT Join/Prune messages will
be used. That is, only PORT Join/Prune messages are accepted from, be used. That is, only PORT Join/Prune messages are accepted from,
and sent to, that particular neighbor. Native Join/Prune messages and sent to, that particular neighbor. Native Join/Prune messages
may still be used for other neighbors. are still used for PIM neighbors that are not PORT enabled.
PORT Join/Prune messages are sent using a TCP/SCTP connection. When 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, two PIM neighbors are PORT enabled, both for TCP or both for SCTP,
they will immediately, or on-demand, establish a connection. If the they will immediately, or on-demand, establish a connection. If the
connection goes down, they will again immediately, or on-demand, try connection goes down, they will again immediately, or on-demand, try
to reestablish the connection. No Join/Prune messages (neither to reestablish the connection. No Join/Prune messages (neither
Native nor PORT) are sent while there is no connection. 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 When PORT is used, only incremental Join/Prune messages are sent from
downstream routers to upstream routers. As such, downstream routers downstream routers to upstream routers. As such, downstream routers
do not generate periodic Join/Prune messages for state for which the do not generate periodic Join/Prune messages for state for which the
RPF neighbor is PORT-capable. RPF neighbor is PORT-capable.
For Joins and Prunes, which are received over a TCP/SCTP connection, For Joins and Prunes, which are received over a TCP/SCTP connection,
the upstream router does not start or maintain timers on the outgoing the upstream router does not start or maintain timers on the outgoing
interface entry. Instead, it keeps track of which downstream routers interface entry. Instead, it keeps track of which downstream routers
have expressed interest. An interface is deleted from the outgoing have expressed interest. An interface is deleted from the outgoing
interface list only when all downstream routers on the interface, no interface list only when all downstream routers on the interface, no
longer wish to receive traffic. longer wish to receive traffic. If there also are native joins/
prunes from non-PORT neighbor, then one can maintain timers on the
outgoing interface entry as usual, while at the same time keep track
of each of the downstream PORT joins/prunes.
There is no change proposed for the PIM Join/Prune packet format. There is no change proposed for the PIM Join/Prune packet format.
However, for Join/Prune messages sent over TCP/SCTP connections, no However, for Join/Prune messages sent over TCP/SCTP connections, no
IP Header is included. The message begins with the PIM common IP Header is included. Each message is contained in a PORT message.
header, followed by the Join/Prune message. See section Section 5 See section Section 5 for details on the PORT message.
for details on the common header.
3. New PIM Hello Options 3. PIM Hello Options
3.1. PIM over the TCP Transport Protocol 3.1. PIM over the TCP Transport Protocol
Option Type: PIM-over-TCP Capable Option Type: PIM-over-TCP Capable
0 1 2 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 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 = X + 8 | | Type = 27 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID AFI | Reserved | Exp | | TCP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID | | TCP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Allocated Hello Type values can be found in [HELLO-OPT]. Allocated Hello Type values can be found in [HELLO-OPT].
When a router is configured to use PIM over TCP on a given interface, 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 it MUST include the PIM-over-TCP Capable hello option in its Hello
messages for that interface. If a router is explicitly disabled from 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 using PIM over TCP, it MUST NOT include the PIM-over-TCP Capable
option in its Hello messages. When the router cannot setup a TCP hello option in its Hello messages.
connection, it will refrain from including this option.
Implementations may provide a configuration option to enable or All Hello messages containing the PIM-over-TCP Capable hello option,
disable PORT functionality. We recommend that this capability be MUST also contain the Interface ID hello option, see section .
Implementations MAY provide a configuration option to enable or
disable PORT functionality. We RECOMMEND that this capability be
disabled by default. disabled by default.
Length: In bytes for the value part of the Type/Length/Value Length: Length in bytes for the value part of the Type/Length/Value
encoding. Where X is 4 bytes if AFI of value 1 (IPv4) is used and encoding; where X is the number of bytes that make up the
16 bytes when AFI of value 2 (IPv6) is used [AFI]. Connection ID field. X is 4 when AFI of value 1 (IPv4) is used,
16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is
used [AFI].
TCP Connection ID AFI: The AFI value to describe the address-family TCP Connection ID AFI: The AFI value to describe the address-family
of the address of the TCP Connection ID field. When this field is of the address of the TCP Connection ID field. When this field is
0, a mechanism outside the scope of this spec is used to obtain 0, a mechanism outside the scope of this document is used to
the addresses used to establish the TCP connection. obtain the addresses used to establish the TCP connection.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
Exp: For experimental use [RFC3692]. Exp: For experimental use [RFC3692].
TCP Connection ID: An IPv4 or IPv6 address used to establish the TCP Connection ID: An IPv4 or IPv6 address used to establish the
TCP connection. This field is omitted (length 0) for the TCP connection. This field is omitted (length 0) for the
Connection ID AFI 0. Connection ID AFI 0.
Interface ID: An Interface ID is used to associate the connection a
Join/Prune message is received over with an interface which is
added or removed from an oif-list. 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 convey the interface from Join/Prune message
sender to Join/Prune message receiver. When a PIM router sets a
locally generated value for the Interface ID in the Hello TLV, it
must send the same Interface ID value in all Join/Prune messages
it is sending to the PIM neighbor.
3.2. PIM over the SCTP Transport Protocol 3.2. PIM over the SCTP Transport Protocol
Option Type: PIM-over-SCTP Capable Option Type: PIM-over-SCTP Capable
0 1 2 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 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 = X + 8 | | Type = 28 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID | | SCTP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | SCTP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Allocated Hello Type values can be found in [HELLO-OPT]. Allocated Hello Type values can be found in [HELLO-OPT].
When a router is configured to use PIM over SCTP on a given 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 interface, it MUST include the PIM-over-SCTP Capable hello option in
its Hello messages for that interface. If a router is explicitly its Hello messages for that interface. If a router is explicitly
disabled from using PIM over SCTP it MUST NOT include the PIM-over- disabled from using PIM over SCTP, it MUST NOT include the PIM-over-
SCTP Capable hello option in its Hello messages. When the router SCTP Capable hello option in its Hello messages.
cannot setup a SCTP connection, it will refrain from including this
option.
Implementations may provide a configuration option to enable or All Hello messages containing the PIM-over-SCTP Capable hello option,
disable PORT functionality. We recommend that this capability be MUST also contain the Interface ID hello option, see section .
Implementations MAY provide a configuration option to enable or
disable PORT functionality. We RECOMMEND that this capability be
disabled by default. disabled by default.
Length: In bytes for the value part of the Type/Length/Value Length: Length in bytes for the value part of the Type/Length/Value
encoding. Where X is 4 bytes if AFI of value 1 (IPv4) is used and encoding; where X is the number of bytes that make up the
16 bytes when AFI of value 2 (IPv6) is used [AFI]. Connection ID field. X is 4 when AFI of value 1 (IPv4) is used,
16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is
used [AFI].
SCTP Connection ID AFI: The AFI value to describe the address- SCTP Connection ID AFI: The AFI value to describe the address-
family of the address of the SCTP Connection ID field. When this family of the address of the SCTP Connection ID field. When this
field is 0, a mechanism outside the scope of this spec is used to field is 0, a mechanism outside the scope of this document is used
obtain the addresses used to establish the SCTP connection. to obtain the addresses used to establish the SCTP connection.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
Exp: For experimental use [RFC3692]. Exp: For experimental use [RFC3692].
SCTP Connection ID: An IPv4 or IPv6 address used to establish the SCTP Connection ID: An IPv4 or IPv6 address used to establish the
SCTP connection. This field is omitted (length 0) for the SCTP connection. This field is omitted (length 0) for the
Connection ID AFI 0. Connection ID AFI 0.
Interface ID: An Interface ID is used to associate the connection a 3.3. Interface ID
Join/Prune message is received over with an interface which is
added or removed from an oif-list. When unnumbered interfaces are All Hello messages containing PIM-over-TCP Capable or PIM-over-SCTP
used or when a single Transport connection is used for sending and Capable hello options, MUST also contain the Interface ID hello
receiving Join/Prune messages over multiple interfaces, the option [I-D.gulrajani-pim-hello-intid].
Interface ID is used convey the interface from Join/Prune message
sender to Join/Prune message receiver. When a PIM router sets a The Interface ID is used to associate the connection a Join/Prune
locally generated value for the Interface ID in the Hello TLV, it message is received over, with an interface which is added or removed
must send the same Interface ID value in all Join/Prune messages from an oif-list. When unnumbered interfaces are used or when a
it is sending to the PIM neighbor. 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 which router the interface
belongs to. 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
[I-D.gulrajani-pim-hello-intid].
4. Establishing Transport Connections 4. Establishing Transport Connections
While a router interface is PORT enabled, a PIM-over-TCP or a PIM- While a router interface is PORT enabled, a PIM-over-TCP or a PIM-
over-SCTP option is included in the PIM Hello messages sent on that over-SCTP option is included in the PIM Hello messages sent on that
interface. When a router on a PORT-enabled interface receives a interface. When a router on a PORT-enabled interface receives a
Hello message containing a PIM-over-TCP/PIM-over-SCTP Option from a Hello message containing a PIM-over-TCP/PIM-over-SCTP Option from a
new neighbor, or an existing neighbor that did not previously include new neighbor, or an existing neighbor that did not previously include
the option, it switches to PORT mode for that particular neighbor. the option, it switches to PORT mode for that particular neighbor.
When a router switches to PORT mode for a neighbor, it stops sending When a router switches to PORT mode for a neighbor, it stops sending
and accepting Native Join/Prune messages for that neighbor. Any and accepting Native Join/Prune messages for that neighbor. Any
state from previous Native Join/Prune messages is left to expire as state from previous Native Join/Prune messages is left to expire as
normal. It will also attempt to establish a Transport connection normal. It will also attempt to establish a Transport connection
(TCP or SCTP) with the neighbor. If both the router and its neighbor (TCP or SCTP) with the neighbor. If both the router and its neighbor
have announced both PIM-over-TCP and PIM-over-SCTP options, SCTP MUST have announced both PIM-over-TCP and PIM-over-SCTP options, SCTP MUST
be used. be used.
When the router is using TCP it will compare the TCP Connection ID it When the router is using TCP, it will compare the TCP Connection ID
announced in the PIM-over-TCP Capable Option with the TCP Connection it announced in the PIM-over-TCP Capable Option with the TCP
ID in the Hello received from the neighbor. The router with the Connection ID in the Hello received from the neighbor. The router
lower Connection ID will do an active Transport open to the neighbor with the lower Connection ID will do an active Transport open to the
Connection ID. The router with the higher Connection ID will do a neighbor Connection ID. The router with the higher Connection ID
passive Transport open. An implementation may open connections only will do a passive Transport open. An implementation may open
on-demand, in that case it may be that the neighbor with the higher connections only on-demand, in that case it may be that the neighbor
Connection ID does the active open, see Section 4.3. Note that the with the higher Connection ID does the active open, see Section 4.5.
source address of the active open must be the announced Connection Note that the source address of the active open must be the announced
ID. Connection ID.
When the router is using SCTP, the IP address comparison need not be When the router is using SCTP, the IP address comparison need not be
done since the SCTP protocol can handle call collision. done since the SCTP protocol can handle call collision.
If PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello If PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello
messages are sent, both containing PORT Hello options. If two messages are sent, both containing PORT Hello options. If two
neighbors announce the same transport (TCP or SCTP) and the same neighbors announce the same transport (TCP or SCTP) and the same
Connection ID in the IPv4 and IPv6 Hello messages, then only one Connection ID in the IPv4 and IPv6 Hello messages, then only one
connection is established and is shared. Otherwise, two connections connection is established and is shared. Otherwise, two connections
are established and are used separately. are established and are used separately.
skipping to change at page 12, line 10 skipping to change at page 12, line 10
When a Transport connection is established (or reestablished), the When a Transport connection is established (or reestablished), the
two routers MUST both send a full set of Join/Prune messages for 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 state for which the other router is the upstream neighbor. This is
needed to ensure that the upstream neighbor has the correct state. needed to ensure that the upstream neighbor has the correct state.
When moving from Datagram mode, or when the connection has gone down, 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 the router cannot be sure that all the previous Join/Prune state was
received by the neighbor. Any state received while in Datagram mode received by the neighbor. Any state received while in Datagram mode
that is not refreshed, will be left to expire. that is not refreshed, will be left to expire.
When a Transport connection goes down, Join/Prune state that was sent It is possible that a router starts sending Hello messages with a new
over the Transport connection is still retained. The neighbor should Connection ID, e.g. due to configuration changes. One MUST always
not be considered down until the neighbor timer has expired. This use the last announced and last seen Connection IDs. When a
allows routers to do a control-plane switchover without disrupting Connection ID changes, if the previously used connection is not
the network. If a Transport connection is reestablished before the needed (there are no other PIM neighborships using the same pair of
neighbor timer expires, the previous state is intact and any new Connection IDs), both peers MUST attempt a graceful shutdown of the
Join/Prune messages sent cause state to be created or removed connection. Next (even if the old connection is still needed), they
(depending on if it was a Join or Prune). If the neighbor timer does MUST, unless a connection already exists with the new Connection IDs,
expire, only the upstream router, that has oif-list state, to the immediately or on-demand attempt to establish a new connection with
expired downstream neighbor will need to clear state. A downstream the new Connection IDs.
router, when an upstream neighboring router has expired, will simply
update the RPF for the corresponding state to a new neighbor where it Normally the Interface ID would not change while a connection is up.
would trigger Join/Prune messages like it would in [RFC4601]. It is However, if it does, it should not affect the connection. It just
required of a PIM router to clear its neighbor table for a neighbor means that when subsequent PORT join/prune messages are received,
who has timed out due to neighbor holdtime expiration. they should be matched against the last seen Interface ID.
Note that, a Join sent over a Transport connection will only be seen Note that, a Join sent over a Transport connection will only be seen
by the upstream router, and thus will not cause routers on the link by the upstream router, and thus will not cause routers on the link
that do not use PIM PORT with the upstream router to possibly delay that do not use PIM PORT with the upstream router to possibly delay
the refresh of Join state for the same state. Similarly, a Prune the refresh of Join state for the same state. Similarly, a Prune
sent over a Transport connection will only be seen by the upstream sent over a Transport connection will only be seen by the upstream
router, and will thus never cause routers on the link on the link router, and will thus never cause routers on the link that do not use
that do not use PIM PORT with the upstream router, to send a Join to PIM PORT with the upstream router, to send a Join to override this
override this Prune. Prune.
Note also, that a datagram PIM Join/Prune message for a said (S,G) or 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 (*,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 same link that use a Transport connection with the upstream router
for that state, to suppress the refresh of that state to the usptream for that state, to suppress the refresh of that state to the upstream
router (because they don't need to periodically refresh this state) router (because they don't need to periodically refresh this state)
or to send a Join to override a Prune (as the upstream router will or to send a Join to override a Prune (as the upstream router will
only stop forwarding the traffic when all joined routers that use a only stop forwarding the traffic when all joined routers that use a
Transport connection have explicitly sent a Prune for this state, as Transport connection have explicitly sent a Prune for this state, as
explained in Section 6). explained in Section 6).
4.1. TCP Connection Maintenance 4.1. Connection Security
TCP/SCTP packets MUST be sent with a TTL/Hop Limit of 255 to
facilitate enabling of the Generalized TTL Security Mechanism (GTSM)
[RFC5082]. Implementations SHOULD provide a configuration option to
enable the GTSM check. This means checking that inbound packets from
directly connected neighbors have a TTL/Hop Limit of 255, but 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].
4.2. Connection Maintenance
TCP is designed to keep connections up indefinitely during a period TCP is designed to keep connections up indefinitely during a period
of network disconnection. If a PIM-over-TCP router fails, the TCP of network disconnection. If a PIM-over-TCP router fails, the TCP
connection may stay up until the neighbor actually reboots, and even connection may stay up until the neighbor actually reboots, and even
then it may continue to stay up until you actually try to send the then it may continue to stay up until you actually try to send the
neighbor some information. This is particularly relevant to PIM, neighbor some information. This is particularly relevant to PIM,
since the flow of Join/Prune messages might be in only one direction, since the flow of Join/Prune messages might be in only one direction,
and the downstream neighbor might never get any indication via TCP and the downstream neighbor might never get any indication via TCP
that the other end of the connection is not really there. that the other end of the connection is not really there.
Implementations SHOULD support the use of TCP Keep-Alives, see One can quicker detect that a PORT connection is not working by
[RFC1122] section 4.2.3.6. We recommend the use of Keep-Alives to be regularly sending PORT messages. PORT in itself does not require any
optional, allowing network administrators to use it as needed. Note periodic signaling. PORT Join/Prune messages are only sent when
that Keep-Alives can be used by a peer, independently of whether the there is a state change. If the state changes are not frequent
other peer supports it. With the use of Keep-Alives one can detect enough, a PORT Keep-Alive message can be sent instead. E.g. if an
that a connection is not working without sending any TCP data. implementation wants to send a PORT message, to check that the
connection is working, at least every 60 seconds, then whenever there
is 60 seconds since the 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. We RECOMMEND
this to be optional, allowing network administrators to use it as
needed. Note that Keep-Alives can be used by a peer, independently
of whether the other peer supports it.
Most applications using TCP want to detect when a neighbor is no As described in the previous paragraph, an implementation can make
longer there, so that the associated application state can be use of Keep-Alives to regularly send messages and detect when a
released. Also, one wants to clean up the TCP state, and not keep connection is not working. For TCP the connection will be reset if
half-open connections around indefinitely. This is accomplished by no TCP ACKs are received. A quicker and more reliable way of
using PIM Hellos and by not introducing an application-specific or detecting that a connection is not working, is to send regular PORT
new PIM keep-alive message. Therefore, when a GENID changes from a messages, and have our peer take down the connection if it doesn't
received PIM Hello message, and a TCP connection is established or receive them. This can be done by sending Keep-alive messages with a
attempting to be established, the local side will tear down the non-zero holdtime value. If the last received Keep-alive message had
connection and attempt to reopen a new one for the new instance of a non-zero holdtime, one tears down the connection if the time
the neighbor coming up. However, if the connection is shared by measured in seconds since the last processed PORT message exceeds the
multiple interfaces and the GENID changes only for one of them, then specified holdtime.
there was not a full reboot and the connection is likely to still
work. In that case, the router should just resend all Join/Prune
state for that particular neighbor. This is similar to how state is
refreshed when GENID changes for PIM in datagram mode.
There may be situations where a router ignores some joins or prunes. Implementations SHOULD support Keep-Alive messages. An
E.g. due to wrong RP information or receiving joins on an RPF implementation that supports Keep-Alive messages acts as follows when
interface. A router may try to cache such messages and apply them processing a received PORT message. When processing a Keep-Alive
later if only a temporary error. It may however also ignore the message with a non-zero Holdtime value, it MUST set a timer to the
message, and later change its GENID for that interface to make the value. We call this timer Connection Expiry Timer (CET). If the CET
neighbor resend all state, including any that may have been is already running, it MUST be reset to the new value. When
previously ignored. It is possible that one receives Join/Prune processing a Keep-Alive message with a zero Holdtime value, the CET
messages for an interface/link that is down. As long as the neighbor MUST be stopped if running. When processing a PORT message other
has not expired, we recommend processing those messages as usual. If than Keep-Alive, the CET MUST be reset to the last received Holdtime
they are ignored, then the router should change the GENID for that value if running. If the CET is not running, no action is taken. If
interface when it comes back up, in order to get a full update. the CET expires, the connection SHOULD be shut down.
4.2. Moving from PORT to Datagram Mode 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, we RECOMMEND processing 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, or by terminating and reestablishing the connection.
There may be situations where an administrator decides to stop using If a PORT neighbor changes its GenID and a connection is established
PORT. If PORT is disabled on a router interface, we start expiry or attempting to be established, the local side should generally tear
timers with the respective neighbor holdtimes as the initial values. down the connection and do as described in Section 4.3. However, if
Similarly if we receive a Hello message without a PORT Capable option the connection is shared by multiple interfaces and the GenID changes
from a neighbor, we start expiry timers for all Join/Prune state we only for one of them, then there was not a full restart, and one may
have for that particular neighbor. The Transport connection should simply send a full update similar to other cases when a GenID changes
be shut down as soon as there are no more PIM neighborships using it. 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 neighborships using it.
That is, for the connection we have associated local and remote That is, for the connection we have associated local and remote
Connection IDs. When there is no PIM neighbor with that particular Connection IDs. When there is no PIM neighbor with that particular
remote connection ID on any interface where we announce the local remote connection ID on any interface where we announce the local
connection ID, the connection should be shut down. 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.
4.3. On-demand versus Pre-configured Connections If a PIM neighbor expires, one should free connection state and
downstream oif-list state for the neighbor. A downstream router,
when an upstream neighboring router has expired, will simply update
the RPF for the corresponding state to a new neighbor where it would
trigger Join/Prune messages like it would in [RFC4601]. 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 connestion
establishment. The neighbors MUST also start expiry timers so that
all oif-list state for the neighbor using the connection, gets
expired after JP_HOLDTIME, unless it later gets refreshed by
receiving new Join/Prunes.
The value of JP_HOLDTIME is 215 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.
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, one follows the rules in Section 4.3 for taking down
connections and starting timers. Next, one should trigger a full
state update similar to what would be done if the GenID changed in
Datagram Mode. This means sending joins for any state where we
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 Transport connections could be established when they are needed or
when a router interface to other PIM neighbors has come up. The when a router interface to other PIM neighbors has come up. The
advantage of on-demand Transport connection establishment is the advantage of on-demand Transport connection establishment is the
reduction of router resources. Especially in the case where there is reduction of router resources. Especially in the case where there is
no need for n^2 connections on a network interface. The disadvantage no need for a full mesh of connections on a network interface. The
is additional delay and queueing when a Join/Prune message needs to disadvantage is additional delay and queueing when a Join/Prune
be sent and a Transport connection is not established yet. message needs to be sent and a Transport connection is not
established yet.
If a router interface has become operational and PIM neighbors are If a router interface has become operational and PIM neighbors are
learned from Hello messages, at that time, Transport connections may learned from Hello messages, at that time, Transport connections may
be established. The advantage is that a connection is ready to be established. The advantage is that a connection is ready to
transport data by the time a Join/Prune message needs to be sent. transport data by the time a Join/Prune message needs to be sent.
The disadvantage is there can be more connections established than The disadvantage is there can be more connections established than
needed. This can occur when there is a small set of RPF neighbors needed. This can occur when there is a small set of RPF neighbors
for the active distribution trees compared to the total number of for the active distribution trees compared to the total number of
neighbors. Even when Transport connections are pre-established neighbors. Even when Transport connections are pre-established
before they are needed, a connection can go down and an before they are needed, a connection can go down and an
skipping to change at page 14, line 40 skipping to change at page 16, line 6
Note that for TCP, it is the router with the lower Connection ID that 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 decides whether to open a connection immediately, or on-demand. The
router with the higher Connection ID should only initiate a router with the higher Connection ID should only initiate a
connection on-demand. That is, if it needs to send a Join/Prune connection on-demand. That is, if it needs to send a Join/Prune
message and there is no currently established connection. message and there is no currently established connection.
Therefore, this specification recommends but does not mandate the use Therefore, this specification recommends but does not mandate the use
of on-demand Transport connection establishment. of on-demand Transport connection establishment.
4.4. Possible Hello Suppression Considerations 4.6. Possible Hello Suppression Considerations
This specification indicates that a Transport connection cannot be This specification indicates that a Transport connection cannot be
established until a Hello message is received. One reason for this established until a Hello message is received. One reason for this
is to determine if the PIM neighbor supports this specification and is to determine if the PIM neighbor supports this specification and
the other is to determine the remote address to use to establish the the other is to determine the remote address to use to establish the
Transport connection. Transport connection.
There are cases where it is desirable to suppress entirely the There are cases where it is desirable to suppress entirely the
transmission of Hello messages. In this case, it is outside the transmission of Hello messages. In this case, it is outside the
scope of this document on how to determine if the PIM neighbor scope of this document on how to determine if the PIM neighbor
supports this specification as well as an out-of-band (outside of the supports this specification as well as an out-of-band (outside of the
PIM protocol) method to determine the remote address to establish the PIM protocol) method to determine the remote address to establish the
Transport connection. Transport connection.
4.5. Avoiding a Pair of Connections between Neighbors 4.7. Avoiding a Pair of TCP Connections between Neighbors
To ensure there are not two connections between a pair of PIM To ensure that there is only one TCP connection between a pair of PIM
neighbors, the following set of rules must be followed. Let A and B neighbors, the following set of rules must be followed. Note that
be two PIM neighbors where A's Connection ID is numerically smaller this section applies only to TCP, for SCTP this is not an issue. Let
than B's Connection ID, and each is known to the other as having a A and B be two PIM neighbors where A's Connection ID is numerically
potential PIM adjacency relationship. smaller than B's Connection ID, and each is known to the other as
having a potential PIM adjacency relationship.
At node A: At node A:
o If there is already an established TCP connection to B, on the 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 PIM-over-TCP port, then A MUST NOT attempt to establish a new
connection to B. Rather it uses the established connection to send connection to B. Rather it uses the established connection to send
Join/Prune messages to B. (This is independent of which node Join/Prune messages to B. (This is independent of which node
initiated the connection.) initiated the connection.)
o If A has initiated a connection to B, but the connection is still o If A has initiated a connection to B, but the connection is still
skipping to change at page 16, line 5 skipping to change at page 18, line 5
PIM-over-TCP port, then B MUST NOT attempt to establish a new PIM-over-TCP port, then B MUST NOT attempt to establish a new
connection to A. Rather it uses the established connection to send connection to A. Rather it uses the established connection to send
Join/Prune messages to A. (This is independent of which node Join/Prune messages to A. (This is independent of which node
initiated the connection.) initiated the connection.)
o If B has initiated a connection to A, but the connection is still 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 in the process of being established, then if A initiates a
connection too, B MUST accept the connection initiated by A and connection too, B MUST accept the connection initiated by A and
must release the connection which it (B) initiated. must release the connection which it (B) initiated.
5. Common Header Definition 5. PORT Message Definition
It may be desirable for scaling purposes to allow Join/Prune messages It may be desirable for scaling purposes to allow Join/Prune messages
from different PIM protocol instances to be sent over the same from different PIM protocol families to be sent over the same
Transport connection. Also, it may be desirable to have a set of Transport connection. Also, it may be desirable to have a set of
Join/Prune messages for one address-family sent over a Transport Join/Prune messages for one address-family sent over a Transport
connection that is established over a different address-family connection that is established over a different address-family
network layer. network layer.
To be able to do this we need a common header that is inserted and To be able to do this we need a common PORT message message format.
parsed for each PIM Join/Prune message that is sent on a Transport This will provide both record boundary and demux points when sending
connection. This common header will provide both record boundary and over a stream protocol like TCP/SCTP.
demux points when sending over a stream protocol like Transport.
Each Join/Prune message will have in front of it the following common A PORT message may contain PORT options, see Section 5.3. We will
header in Type/Length/Value format. And multiple different TLV types define two PORT options for carrying PIM Join/Prune messages. One
can be sent over the same Transport connection. 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 below 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 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 transport layer receives the Join/Prune buffer, the TCP Push flag
will be set in all outgoing Join/Prune messages sent over a TCP will be set in all outgoing Join/Prune messages sent over a TCP
transport connection. transport connection.
PIM messages will be sent using destination TCP port number 8471. PORT messages will be sent using destination TCP port number 8471.
When using SCTP as the reliable transport, destination port number When using SCTP as the reliable transport, destination port number
8471 will be used. See Section 10 for IANA considerations. 8471 will be used. See Section 10 for IANA considerations.
Join/Prune messages are error checked. This includes a bad PIM PORT messages are error checked. This includes a bad PIM checksum,
checksum, illegal type fields, illegal addresses or a truncated illegal type fields, illegal addresses or a truncated message. If
message. If any parsing errors occur in a Join/Prune message, it is any parsing errors occur in a Join/Prune message, it is skipped, and
skipped, and we proceed processing any following TLVs. we proceed processing any following PORT messages.
The TLV type field is 16 bits. The range 61440 - 65535 is for The TLV type field is 16 bits. The range 61440 - 65535 is for
experimental use [RFC3692]. experimental use [RFC3692].
The current list of defined TLVs are: This document defines two message types.
IPv4 Join/Prune Message 5.1. PORT Join/Prune Message
PORT Join/Prune Message
0 1 2 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 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 | Length = X + 16 | | Type = 1 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Exp |I-Type | | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface |
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID . . . | | PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Instance ID | | Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 Join/Prune Message | \ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 Join/Prune common header is used when a Join/Prune message The PORT Join/Prune Message is used for sending a PIM Join/Prune.
is sent that has all IPv4 encoded addresses in the PIM payload.
Length: In bytes for the value part of the Type/Length/Value Message Length: Length in bytes for the value part of the Type/
encoding. Where X is the number of bytes that make up the PIMv2 Length/Value encoding. If no PORT Options were included, the
Join/Prune message. length would be 12. If n PORT Options with Option Value lengths
L1, L2, ..., Ln are included, the message length will be 12 + 4*n
+ L1 + L2 + ... + Ln.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
Exp: For experimental use [RFC3692]. Exp: For experimental use [RFC3692].
I-Type: Defines the encoding and semantics of the Instance ID Interface ID: This is the Interface ID of the Interface ID Hello
field. Instance Type 0 means Instance ID is not used. Other option contained in the PIM Hello messages the PIM router is
values are not defined in this specification. A message with an sending to the PIM neighbor. It indicates to the PIM neighbor
unknown Instance Type MUST be ignored. what interface to associate the Join/Prune with.
Interface ID: This is the Interface ID from the Hello TLV, defined PORT Options: The message MUST contain exactly one PIM Join/Prune
in this specification, the PIM router is sending to the PIM Port Option, either one PIM IPv4 Join/Prune or one PIM IPv6 Join/
neighbor. It indicates to the PIM neighbor what interface to Prune. It MUST NOT contain both. It MAY contain additional
associate the Join/Prune with. options not defined in this document. A router receiving a PORT
Join/Prune message containing unknown options MUST ignore the
entire PORT message. See Section 5.3 for option definitions.
Instance ID: This document only defines this for Instance Type 0. As can be seen from the packet format diagram, multiple Join/Prune
For type 0 the field should be set to zero on transmission and messages can go into one TCP/SCTP stream from the same or different
ignored on receipt. This field is always 64 bits. Interface IDs.
PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with 5.2. PORT Keep-alive Message
no IP header in front of it. As you can see from the packet
format diagram, multiple Join/Prune messages can go into one TCP/
SCTP stream from the same or different Interface and Instance IDs.
IPv6 Join/Prune Message PORT Keep-alive Message
0 1 2 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 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 | Length = X + 16 | | Type = 2 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Exp |I-Type | | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Holdtime | PORT Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID . . . | | Option Value Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Instance ID | \ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 Join/Prune Message | | PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Join/Prune common header is used when a Join/Prune message The PORT Keep-alive Message is used to regularly send PORT messages
is sent that has all IPv6 encoded addresses in the PIM payload. to verify that a connection is alive. They are used when other PORT
messages are not sent of the desired frequency.
Length: In bytes for the value part of the Type/Length/Value Message Length: Length in bytes for the value part of the Type/
encoding. Where X is the number of bytes that make up the PIMv2 Length/Value encoding. If no PORT Options were included, the
Join/Prune message. length would be 6. If n PORT Options with Option Value lengths
L1, L2, ..., Ln are included, the message length will be 6 + 4*n +
L1 + L2 + ... + Ln.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
Exp: For experimental use [RFC3692]. Exp: For experimental use [RFC3692].
I-Type: Defines the encoding and semantics of the Instance ID Holdtime: This specifies a holdtime in seconds for the connection.
field. Instance Type 0 means Instance ID is not used. Other A non-zero value means that the connection SHOULD be gracefully
values are not defined in this specification. 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 one PORT message has been processed until
the next has been processed. Note that this is done for any PORT
message, not just keep-alive messages. A hold time of 0 disables
the keep-alive mechanism.
Interface ID: This is the Interface ID from the Hello TLV, defined PORT Options: A keep-alive message MUST NOT contain any of the
in this specification, the PIM router is sending to the PIM options defined in this document. It MAY contain other options
neighbor. It indicates to the PIM neighbor what interface to not defined in this document. See Section 5.3 for option
associate the Join/Prune with. definitions.
Instance ID: This document only defines this for Instance Type 0. 5.3. PORT Options
For type 0 the field should be set to zero on transmission and
ignored on receipt. Each PORT Option is a TLV. The type is 16 bits. PORT Option types
are assigned by IANA, except the range 61440 - 65535 which is for
experimental use [RFC3692]. The length specifies the length of the
value in bytes. Below are the two options defined in this document.
PIM IPv4 Join/Prune Option
PIM IPv4 Join/Prune Option Format
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 |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with
no IP header in front of it. As you can see from the packet no IP header in front of it.
format diagram, multiple Join/Prune messages can go into one TCP/
SCTP stream from the same or different Interface and Instance IDs. PIM IPv6 Join/Prune Option
PIM IPv6 Join/Prune Option Format
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 |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
6. Explicit Tracking 6. Explicit Tracking
When explicit tracking is used, a router keeps track of join state When explicit tracking is used, a router keeps track of join state
for individual downstream neighbors on a given interface. This is for individual downstream neighbors on a given interface. This is
done for all PORT joins and prunes. It may also be done for native done for all PORT joins and prunes. It may also be done for native
join/prune messages, if all neighbors on the LAN have set the T bit join/prune messages, if all neighbors on the LAN have set the T bit
of the LAN Prune Delay option. In the discussion below we will talk of the LAN Prune Delay option. In the discussion below we will talk
about ET (explicit tracking) neighbors, and non-ET neighbors. The about ET (explicit tracking) neighbors, and non-ET neighbors. The
set of ET neighbors always includes the PORT neighbors. The set of set of ET neighbors always includes the PORT neighbors. The set of
skipping to change at page 20, line 27 skipping to change at page 23, line 27
For some link-types, e.g. point-to-point, tracking neighbors is no For some link-types, e.g. point-to-point, tracking neighbors is no
different than tracking interfaces. It may also be possible for an different than tracking interfaces. It may also be possible for an
implementation to treat different downstream neighbors as being on implementation to treat different downstream neighbors as being on
different logical interfaces, even if they are on the same physical different logical interfaces, even if they are on the same physical
link. Exactly how this is implemented and for which link types, is link. Exactly how this is implemented and for which link types, is
left to the implementer. left to the implementer.
For (*,G) and (S,G) state, the router starts forwarding traffic on an 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 Join is received from a neighbor on such an
interface. When a non-ET neighbor sends a Prune, there is generally interface. When a non-ET neighbor sends a Prune, as specified
a small delay to see if another non-ET neighbor sends a Join to [RFC4601], if no Join is sent to override this Prune before the
override the Prune. If there is no override, one should note that no expiration of the Override Timer, the upstream router concludes that
non-ETP neighbor is interested. If no ET neighbors are interested, no non-ET neighbor is interested. If no ET neighbors are interested,
the interface can be removed from the oif-list. When a ET neighbor 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 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 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 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 can be no Prune Override, since the Prune is not visible to other
neighbors. neighbors.
For (S,G,R) state, the router needs to track Prune state on the 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, shared tree. It needs to know which ET neighbors have sent prunes,
and whether any non-ET neighbors have sent prunes. Normally one 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 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,R)-prune. With ET interface if a (*,G)-join is received, but no (S,G,rpt)-prune. With
one needs to do this check per ET neighbor. That is, the packet ET one needs to do this check per ET neighbor. That is, the packet
should be forwarded unless all ET neighbors that have sent should be forwarded unless all ET neighbors that have sent
(*,G)-joins have also sent (S,G,R)-prunes, and if a non-ET neighbor (*,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,R)-prune has sent a (*,G)-join, whether there also is non-ET (S,G,rpt)-prune
state. state.
7. Multiple Instances and Address-Family Support 7. Multiple Address-Family Support
Multiple instances of the PIM protocol may be used to support e.g.
multiple address families. Multiple instances can cause a multiplier
effect on the number of router resources consumed. To be able to
have an option to use router resources more efficiently, muxing Join/
Prune messages over fewer Transport connections can be performed.
There are two ways this can be accomplished, one using a common To allow for efficient use of router resources, one can mux Join/
header format over a TCP connection and the other using multiple Prune messages of different address families on the same Transport
streams over a single SCTP connection. connections. There are two ways this can be accomplished, one using
a common message format over a TCP connection and the other using
multiple streams over a single SCTP connection.
Using the Common Header format described previously in this Using the common message format described previously in this
specification, using different TLVs, both IPv4 and IPv6 based Join/ specification, using different PORT options, both IPv4 and IPv6 based
Prune messages can be encoded within a Transport connection. Join/Prune messages can be encoded within the same Transport
Likewise, within a TLV, multiple occurrences of Join/Prune messages
can occur and are tagged with an instance-ID so multiple Join/Prune
messages for different instances can use a single Transport
connection. connection.
When using SCTP multi-streaming, the common header is still used to When using SCTP multi-streaming, the common message format is still
convey instance information but an SCTP association is used, on a used to convey address family information but an SCTP association is
per-instance basis, to send data concurrently for multiple instances. used, on a per-family basis, to send data concurrently for multiple
When data is sent concurrently, head of line blocking, which can families. When data is sent concurrently, head of line blocking,
occur when using TCP, is avoided. which can occur when using TCP, is avoided.
8. Miscellany 8. Miscellany
No changes expected in processing of other PIM messages like PIM No changes expected in processing of other PIM messages like PIM
Asserts, Grafts, Graft-Acks, Registers, and Register-Stops. This Asserts, Grafts, Graft-Acks, Registers, and Register-Stops. This
goes for BSR and Auto-RP type messages as well. goes for BSR and Auto-RP type messages as well.
This extension is applicable only to PIM-SM, PIM-SSM and Bidir-PIM. This extension is applicable only to PIM-SM, PIM-SSM and Bidir-PIM.
It does not take requirements for PIM-DM into consideration. It does not take requirements for PIM-DM into consideration.
9. Security Considerations 9. Security Considerations
Transport connections can be authenticated using HMACs MD5 and SHA-1 TCP connections can be authenticated using TCP-AO [RFC5925]. When
similar to use in BGP [RFC4271] and MSDP [RFC3618]. using SCTP, [RFC4895] can be used for authentication on a per SCTP
association basis. Also GTSM [RFC5082] can be used to help prevent
When using SCTP as the transport protocol, [RFC4895] can be used, on spoofing.
a per SCTP association basis to authenticate PIM data.
10. IANA Considerations 10. IANA Considerations
This specification makes use of a TCP port number and a SCTP port This specification makes use of a TCP port number and a SCTP port
number for the use of PIM-Over-Reliable-Transport that has been number for the use of PIM-Over-Reliable-Transport that has been
allocated by IANA. It also makes use of IANA PIM Hello Options allocated by IANA. It also makes use of IANA PIM Hello Options
allocations that should be made permanent. In addition, a registry allocations that should be made permanent.
for PORT message types is requested. The registry should cover the
range 0 - 61439. An RFC is required for assignments in that range. 10.1. PORT Message Type Registry
This document defines two PORT message types. Type 1, IPv4 Join/
Prune Message; and Type 2, IPv6 Join/Prune Message. The type range A registry for PORT message types is requested. The message type is
a 16-bit integer, with values from 0 to 65535. An RFC is required
for assignments in the range 0 - 61439. This document defines one
PORT message type. Type 1, PORT Join/Prune Message. The type range
61440 - 65535 is for experimental use [RFC3692]. 61440 - 65535 is for experimental use [RFC3692].
The initial content of the registry should be as follows:
Type Name Reference
------------- ------------------------------- ---------------
0 Reserved this document
1 Join/Prune this document
2 Keep-alive Message this document
3-61439 Unassigned
61440-65535 Experimental this document
10.2. PORT Option Type Registry
A registry for PORT option types is requested. The option type is a
16-bit integer, with values from 0 to 65535. An RFC is required for
assignments in the range 0 - 61439. This document defines two PORT
option types. Type 1, PIM IPv4 Join/Prune Message; and Type 2, PIM
IPv6 Join/Prune Message. The type range 61440 - 65535 is for
experimental use [RFC3692].
The initial content of the registry should be as follows:
Type Name Reference
------------- ------------------------------- ---------------
0 Reserved this document
1 PIM IPv4 Join/Prune Message this document
2 PIM IPv6 Join/Prune Message this document
3-61439 Unassigned
61440-65535 Experimental this document
11. Contributors 11. Contributors
In addition to the persons listed as authors, significant In addition to the persons listed as authors, significant
contributions were provided by Apoorva Karan and Arjen Boers. contributions were provided by Apoorva Karan and Arjen Boers.
12. Acknowledgments 12. Acknowledgments
The authors would like to give a special thank you and appreciation The authors would like to give a special thank you and appreciation
to Nidhi Bhaskar for her initial design and early prototype of this to Nidhi Bhaskar for her initial design and early prototype of this
idea. idea.
Appreciation goes to Randall Stewart for his authoritative review and Appreciation goes to Randall Stewart for his authoritative review and
recommendation for using SCTP. recommendation for using SCTP.
Thanks also goes to the following for their ideas and commentary Thanks also goes to the following for their ideas and commentary
review of this specification, Mike McBride, Toerless Eckert, Yiqun review of this specification, Mike McBride, Toerless Eckert, Yiqun
Cai, Albert Tian, Suresh Boddapati, Nataraj Batchu, Daniel Voce, John Cai, Albert Tian, Suresh Boddapati, Nataraj Batchu, Daniel Voce, John
Zwiebel, Yakov Rekhter, Lenny Giuliano, Gorry Fairhurst, Sameer Zwiebel, Yakov Rekhter, Lenny Giuliano, Gorry Fairhurst, Sameer
Gulrajani, Thomas Morin and Dimitri Papadimitriou. Gulrajani, Thomas Morin, Dimitri Papadimitriou, Bharat Joshi, Rishabh
Parekh, Manav Bhatia and Pekka Savola.
A special thank you goes to Eric Rosen for his very detailed review 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 and commentary. Many of his comments are reflected as text in this
specification. specification.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.gulrajani-pim-hello-intid]
Gulrajani, S. and S. Venaas, "An Interface ID Hello Option
for PIM", draft-gulrajani-pim-hello-intid-00 (work in
progress), February 2011.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission "Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, August 2007. Protocol (SCTP)", RFC 4895, August 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
[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.
13.2. Informative References 13.2. Informative References
[AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/numbers.html, February 2007. NUMBERS http://www.iana.org/numbers.html, February 2007.
[HELLO-OPT] [HELLO-OPT]
IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per
RFC4601 http://www.iana.org/assignments/pim-hello-options, RFC4601 http://www.iana.org/assignments/pim-hello-options,
March 2007. March 2007.
 End of changes. 97 change blocks. 
286 lines changed or deleted 471 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/