draft-ietf-pim-port-08.txt   draft-ietf-pim-port-09.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: March 1, 2012 cisco Systems Expires: April 26, 2012 cisco Systems
M. Napierala M. Napierala
AT&T Labs AT&T Labs
August 29, 2011 October 24, 2011
A Reliable Transport Mechanism for PIM A Reliable Transport Mechanism for PIM
draft-ietf-pim-port-08.txt draft-ietf-pim-port-09.txt
Abstract Abstract
This document defines a reliable transport mechanism for the PIM This document defines a reliable transport mechanism for the PIM
protocol for transmission of Join/Prune messages. This eliminates protocol for transmission of Join/Prune messages. This eliminates
the need for periodic Join/Prune message transmission and processing. the need for periodic Join/Prune message transmission and processing.
The reliable transport mechanism can use either TCP or SCTP as the The reliable transport mechanism can use either TCP or SCTP as the
transport protocol. 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 March 1, 2012. This Internet-Draft will expire on April 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
4. Establishing Transport Connections . . . . . . . . . . . . . . 11 4. Establishing Transport Connections . . . . . . . . . . . . . . 11
4.1. Connection Security . . . . . . . . . . . . . . . . . . . 13 4.1. Connection Security . . . . . . . . . . . . . . . . . . . 13
4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 13 4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 13
4.3. Actions When a Connection Goes Down . . . . . . . . . . . 15 4.3. Actions When a Connection Goes Down . . . . . . . . . . . 15
4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 15 4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 15
4.5. On-demand versus Pre-configured Connections . . . . . . . 16 4.5. On-demand versus Pre-configured Connections . . . . . . . 16
4.6. Possible Hello Suppression Considerations . . . . . . . . 16 4.6. Possible Hello Suppression Considerations . . . . . . . . 16
4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 17 4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 17
5. PORT Message Definitions . . . . . . . . . . . . . . . . . . . 18 5. PORT Message Definitions . . . . . . . . . . . . . . . . . . . 18
5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 19 5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 19
5.2. PORT Keep-alive Message . . . . . . . . . . . . . . . . . 20 5.2. PORT Keep-alive Message . . . . . . . . . . . . . . . . . 21
5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 21 5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.1. PIM IPv4 Join/Prune Option . . . . . . . . . . . . . . 22 5.3.1. PIM IPv4 Join/Prune Option . . . . . . . . . . . . . . 22
5.3.2. PIM IPv6 Join/Prune Option . . . . . . . . . . . . . . 22 5.3.2. PIM IPv6 Join/Prune Option . . . . . . . . . . . . . . 23
6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 24 6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 24
7. Multiple Address-Family Support . . . . . . . . . . . . . . . 25 7. Multiple Address-Family Support . . . . . . . . . . . . . . . 25
8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Manageability Considerations . . . . . . . . . . . . . . . . . 27 9. Transport Considerations . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Manageability Considerations . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11.1. PORT Port Number . . . . . . . . . . . . . . . . . . . . . 29 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11.2. PORT Hello Options . . . . . . . . . . . . . . . . . . . . 29 12.1. PORT Port Number . . . . . . . . . . . . . . . . . . . . . 30
11.3. PORT Message Type Registry . . . . . . . . . . . . . . . . 29 12.2. PORT Hello Options . . . . . . . . . . . . . . . . . . . . 30
11.4. PORT Option Type Registry . . . . . . . . . . . . . . . . 29 12.3. PORT Message Type Registry . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.4. PORT Option Type Registry . . . . . . . . . . . . . . . . 30
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . . 33 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.2. Informative References . . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 15.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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
Join/Prune message delivery in PIM version 2 for use with PIM Join/Prune message delivery in PIM version 2 for use with PIM
Sparse-Mode [RFC4601] (including Source-Specific Multicast) and Sparse-Mode [RFC4601] (including Source-Specific Multicast) and
Bidirectional PIM [RFC5015]. Bidirectional PIM [RFC5015].
skipping to change at page 3, line 31 skipping to change at page 3, line 31
o Provide support for automatic switching between the reliable o Provide support for automatic switching between the reliable
transport mechanism and the regular PIM mechanism defined in transport mechanism and the regular PIM mechanism defined in
[RFC4601]. Two routers that are PIM neighbors on a link will [RFC4601]. Two routers that are PIM neighbors on a link will
always use the reliable transport mechanism if and only if both always use the reliable transport mechanism if and only if both
have enabled support for the reliable transport mechanism. have enabled support for the reliable transport mechanism.
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. The destination port number is 8471 for both TCP and SCTP.
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 PIM state and the overhead links that comes at the price of increased PIM state and the overhead
required to maintain this state. required to maintain this state.
In many existing and emerging networks, particularly wireless and In many existing and emerging networks, particularly wireless and
mobile satellite systems, link degradation due to weather, mobile satellite systems, link degradation due to weather,
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
skipping to change at page 6, line 21 skipping to change at page 6, line 21
PORT only applies to PIM Sparse-Mode [RFC4601] and Bidirectional PIM PORT only applies to PIM Sparse-Mode [RFC4601] and Bidirectional PIM
[RFC5015] Join/Prune messages. [RFC5015] Join/Prune messages.
This document does not restrict PORT to any specific link types. 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 However, the use of PORT on e.g. multi-access LANs with many PIM
neighbors should be carefully evaluated. This due to the fact that neighbors should be carefully evaluated. This due to the fact that
there may be a full mesh of PORT connections, and that explicit there may be a full mesh of PORT connections, and that explicit
tracking of all PIM PORT routers is required. tracking of all PIM PORT routers is required.
PORT can be incrementally used on a link between PORT capable PORT can be incrementally used on a link between PORT-capable
neighbors. Routers that are not PORT capable can continue to use PIM neighbors. Routers that are not PORT-capable can continue to use PIM
in Datagram Mode. PORT capability is detected using new PORT Capable in Datagram Mode. PORT capability is detected using new PORT-Capable
PIM Hello Options. 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
are still used for PIM neighbors that are not PORT enabled. 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,
skipping to change at page 8, line 9 skipping to change at page 8, line 9
This document does not update the PIM Join/Prune packet format. In This document does not update the PIM Join/Prune packet format. In
the procedures described in this document, each PIM Join/Prune the procedures described in this document, each PIM Join/Prune
message is included in the payload of a PORT message carried over message is included in the payload of a PORT message carried over
TCP/SCTP. See section Section 5 for details on the PORT message. TCP/SCTP. See section Section 5 for details on the PORT message.
3. 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 = 4 + X | | Type = 27 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID AFI | Reserved | Exp | | TCP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID | | TCP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Allocated Hello Type values can be found in [HELLO-OPT]. Assigned 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 using PIM over TCP, it MUST NOT include the PIM-over-TCP-Capable
hello option in its Hello messages. hello option in its Hello messages.
All Hello messages containing the PIM-over-TCP Capable hello option, All Hello messages containing the PIM-over-TCP-Capable hello option,
MUST also contain the Interface ID hello option, see section MUST also contain the Interface ID hello option, see section
Section 3.3. Section 3.3.
Implementations MAY provide a configuration option to enable or Implementations MAY provide a configuration option to enable or
disable PORT functionality. It is RECOMMENDED that this capability disable PORT functionality. It is RECOMMENDED that this capability
be disabled by default. be disabled by default.
Length: 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 the number of bytes that make up the 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 Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is
skipping to change at page 9, line 19 skipping to change at page 9, line 19
router supports an experimental feature, it may set a bit to router supports an experimental feature, it may set a bit to
indicate this. The default behavior, unless a router supports a indicate this. The default behavior, unless a router supports a
particular experiment, is to ignore the bits on receipt. particular experiment, is to ignore the bits on receipt.
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.
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 = 4 + X | | Type = 28 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID AFI | Reserved | Exp | | SCTP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID | | SCTP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Allocated Hello Type values can be found in [HELLO-OPT]. Assigned 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. SCTP-Capable hello option in its Hello messages.
All Hello messages containing the PIM-over-SCTP Capable hello option, All Hello messages containing the PIM-over-SCTP-Capable hello option,
MUST also contain the Interface ID hello option, see section MUST also contain the Interface ID hello option, see section
Section 3.3. Section 3.3.
Implementations MAY provide a configuration option to enable or Implementations MAY provide a configuration option to enable or
disable PORT functionality. It is RECOMMENDED that this capability disable PORT functionality. It is RECOMMENDED that this capability
be disabled by default. be disabled by default.
Length: 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 the number of bytes that make up the 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 Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is
skipping to change at page 10, line 30 skipping to change at page 10, line 30
router supports an experimental feature, it may set a bit to router supports an experimental feature, it may set a bit to
indicate this. The default behavior, unless a router supports a indicate this. The default behavior, unless a router supports a
particular experiment, is to ignore the bits on receipt. particular experiment, is to ignore the bits on receipt.
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.
3.3. Interface ID 3.3. Interface ID
All Hello messages containing PIM-over-TCP Capable or PIM-over-SCTP All Hello messages containing PIM-over-TCP-Capable or PIM-over-SCTP-
Capable hello options, MUST also contain the Interface ID hello Capable hello options, MUST also contain the Interface ID hello
option [I-D.ietf-pim-hello-intid]. option [RFC6395].
The Interface ID is used to associate a PORT Join/Prune message with The Interface ID is used to associate a PORT Join/Prune message with
the PIM neighbor that it is coming from. When unnumbered interfaces the PIM neighbor that it is coming from. When unnumbered interfaces
are used or when a single Transport connection is used for sending are used or when a single Transport connection is used for sending
and receiving Join/Prune messages over multiple interfaces, the and receiving Join/Prune messages over multiple interfaces, the
Interface ID is used to convey the interface from Join/Prune message Interface ID is used to convey the interface from Join/Prune message
sender to Join/Prune message receiver. The value of the Interface ID 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 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 Interface ID value in all PORT Join/Prune messages sent to a PIM
neighbor on that interface. neighbor on that interface.
The Interface ID need only uniquely identify an interface of a The Interface ID need only uniquely identify an interface of a
router, it does not need to identify which router the interface router, it does not need to identify which router the interface
belongs to. This means that the Router ID part of the Interface ID 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 MAY be 0. For details on the Router ID and the value 0, see
[I-D.ietf-pim-hello-intid]. [RFC6395].
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 MUST be included in the PIM Hello messages sent on over-SCTP option MUST be included in the PIM Hello messages sent on
that interface. When a router on a PORT-enabled interface receives a that 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.
skipping to change at page 11, line 26 skipping to change at page 11, line 26
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. This resolves the issue where two transports are both be used. This resolves the issue where two transports are both
offered. The method prefers SCTP over TCP, because SCTP has benefits offered. The method prefers SCTP over TCP, because SCTP has benefits
such as call collision handling and support for multiple streams, as such as call collision handling and support for multiple streams, as
discussed later in this document. discussed later in this document.
When the router is using TCP, it will compare the TCP Connection ID 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 it announced in the PIM-over-TCP-Capable Option with the TCP
Connection ID in the Hello received from the neighbor. Unless Connection ID in the Hello received from the neighbor. Unless
connections are opened on-demand (see below), the router with the connections are opened on-demand (see below), the router with the
lower Connection ID MUST do an active Transport open to the neighbor lower Connection ID MUST do an active Transport open to the neighbor
Connection ID. The router with the higher Connection ID MUST do a Connection ID. The router with the higher Connection ID MUST do a
passive Transport open. An implementation MAY open connections only passive Transport open. An implementation MAY open connections only
on-demand, in that case it may be that the neighbor with the higher 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 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- 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 demand, it MUST do a passive open, allowing for the neighbor to
initiate the connection. Note that the source address of the active initiate the connection. Note that the source address of the active
open MUST be the announced Connection ID. open MUST be the announced 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 The decisions whether to use PORT, which transport, and which
messages MUST be sent, both containing PORT Hello options. If two Connection IDs to use are performed independently for IPv4 and IPv6.
neighbors announce the same transport (TCP or SCTP) and the same Thus, if PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM
Connection ID in the IPv4 and IPv6 Hello messages, then only one 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 connection is established and is shared. Otherwise, two connections
are established and are used separately. are established and are used separately.
The PIM router that performs the active open initiates the connection The PIM router that performs the active open initiates the connection
with a locally generated source transport port number and a well- with a locally generated source transport port number and a well-
known destination transport port number. The PIM router that known destination transport port number. The PIM router that
performs the passive open listens on the well-known local transport performs the passive open listens on the well-known local transport
port number and does not qualify the remote transport port number. port number and does not qualify the remote transport port number.
See Section 5 for well-known port number assignment for PORT. See Section 5 for well-known port number assignment for PORT.
skipping to change at page 13, line 41 skipping to change at page 13, line 43
router hops. The GTSM check SHOULD be disabled by default. router hops. The GTSM check SHOULD be disabled by default.
Implementations SHOULD support the TCP Authentication Option (TCP-AO) Implementations SHOULD support the TCP Authentication Option (TCP-AO)
[RFC5925] and SCTP Authenticated Chunks [RFC4895]. [RFC5925] and SCTP Authenticated Chunks [RFC4895].
4.2. Connection Maintenance 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 PORT tries to send the neighbor
neighbor some information. This is particularly relevant to PIM, some information. This is particularly relevant to PIM, since the
since the flow of Join/Prune messages might be in only one direction, flow of Join/Prune messages might be in only one direction, and the
and the downstream neighbor might never get any indication via TCP downstream neighbor might never get any indication via TCP that the
that the other end of the connection is not really there. other end of the connection is not really there.
SCTP has a heart beat mechanism that can be used to detect that a SCTP has a heart beat mechanism that can be used to detect that a
connection is working, even when no data is sent. 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 it 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 One can detect that a PORT connection is not working by regularly
sending PORT messages. This applies to both TCP and SCTP. E.g., for sending PORT messages. This applies to both TCP and SCTP. E.g., for
TCP the connection will be reset if no TCP ACKs are received after a TCP the connection will be reset if no TCP ACKs are received after
few retries. PORT in itself does not require any periodic signaling. several retries. PORT in itself does not require any periodic
PORT Join/Prune messages are only sent when there is a state change. signaling. PORT Join/Prune messages are only sent when there is a
If the state changes are not frequent enough, a PORT Keep-Alive state change. If the state changes are not frequent enough, a PORT
message (defined in Section 5.2) can be sent instead. E.g., if an Keep-Alive message (defined in Section 5.2) can be sent instead.
implementation wants to send a PORT message, to check that the E.g., if an implementation wants to send a PORT message, to check
connection is working, at least every 60 seconds, then whenever there that the connection is working, at least every 60 seconds, then
is 60 seconds since the previous message, a Keep-Alive message could whenever there is 60 seconds since the previous message, a Keep-Alive
be sent. If there were less than 60 seconds between each Join/Prune, message could be sent. If there were less than 60 seconds between
no Keep-Alive messages would be needed. Implementations SHOULD each Join/Prune, no Keep-Alive messages would be needed.
support the use of PORT Keep-Alive messages. It is RECOMMENDED that Implementations SHOULD support the use of PORT Keep-Alive messages.
a configuration option is available to network administrators to It is RECOMMENDED that a configuration option is available to network
enable it when needed. Note that Keep-Alives can be used by a peer, administrators to enable it when needed. Note that Keep-Alives can
independently of whether the other peer supports it. be used by a peer, independently of whether the other peer supports
it.
An implementation that supports Keep-Alive messages acts as follows An implementation that supports Keep-Alive messages acts as follows
when processing a received PORT message. When processing a Keep- when processing a received PORT message. When processing a Keep-
Alive message with a non-zero Holdtime value, it MUST set a timer to 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 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 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 processing a Keep-Alive message with a zero Holdtime value, the CET
MUST be stopped if running. When processing a PORT message other MUST be stopped if running. When processing a PORT message other
than Keep-Alive, the CET MUST be reset to the last received Holdtime than 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 value if running. If the CET is not running, no action is taken. If
skipping to change at page 18, line 34 skipping to change at page 18, line 34
Each PORT message will have the Type/Length/Value format. Multiple Each PORT message will have the Type/Length/Value format. Multiple
different TLV types can be sent over the same Transport connection. 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.
PORT 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 11 for IANA considerations. 8471 will be used. See Section 12 for IANA considerations.
PORT messages are error checked. This includes illegal type fields, PORT messages are error checked. This includes unknown/illegal type
or a truncated message. If the PORT message contains a PIM Join/ fields, or a truncated message. If the PORT message contains a PIM
Prune Message, then that is subject to the normal PIM error checks. Join/Prune Message, then that is subject to the normal PIM error
If any parsing errors occur in a PORT message, it is skipped, and we checks, including checksum verification. If any parsing errors occur
proceed to any following PORT messages. 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 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. E.g., 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 The TLV type field is 16 bits. The range 65532 - 65535 is for
experimental use [RFC3692]. experimental use [RFC3692].
This document defines two message types. This document defines two message types.
5.1. PORT Join/Prune Message 5.1. PORT Join/Prune Message
PORT Join/Prune Message PORT Join/Prune Message
skipping to change at page 24, line 8 skipping to change at page 24, line 8
Option Value Length: The number of bytes that make up the PIMv2 Option Value Length: The number of bytes that make up the PIMv2
Join/Prune message. 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. 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 MUST
done for all PORT joins and prunes. It may also be done for native be done for all PORT joins and prunes. Note that it may also be done
join/prune messages, if all neighbors on the LAN have set the T bit for native join/prune messages, if all neighbors on the LAN have set
of the LAN Prune Delay option (see definition in section 4.9.2 of the T bit of the LAN Prune Delay option (see definition in section
[RFC4601]). In the discussion below we will talk about ET (explicit 4.9.2 of [RFC4601]). In the discussion below we will talk about ET
tracking) neighbors, and non-ET neighbors. The set of ET neighbors (explicit tracking) neighbors, and non-ET neighbors. The set of ET
MUST include the PORT neighbors. The set of non-ET neighbors neighbors MUST include the PORT neighbors. The set of non-ET
consists of all the non-PORT neighbors unless all neighbors have set neighbors consists of all the non-PORT neighbors unless all neighbors
the LAN Prune Delay T bit. Then the ET neighbors set contains all have set the LAN Prune Delay T bit. Then the ET neighbors set
neighbors. contains all neighbors.
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
skipping to change at page 27, line 5 skipping to change at page 27, line 5
8. Miscellany 8. Miscellany
There are no changes to processing of other PIM messages like PIM There are no changes to 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. Manageability Considerations 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 is
unclear, although 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
can configure whether to use keep-alives, what holdtimes etc.
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 making 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 as discussed in the previous paragraph that
only occasional small messages are sent. 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].
While the above two paragraphs only discuss TCP issues, there may
also be similar issues regarding SCTP.
10. Manageability Considerations
This document defines using TCP or SCTP transports between pairs of This document defines using TCP or SCTP transports between pairs of
PIM neighbors. It is recommended that this mechanism is disabled by PIM neighbors. It is recommended that this mechanism is disabled by
default. An administrator can then enable PORT TCP and/or SCTP on default. An administrator can then enable PORT TCP and/or SCTP on
PIM enabled interfaces. If two neighbors both have PORT SCTP (and if PIM enabled interfaces. If two neighbors both have PORT SCTP (and if
not, if both PORT TCP) they will only use SCTP (alternatively TCP) not, if both PORT TCP) they will only use SCTP (alternatively TCP)
for PIM Join/Prune messages. This is the case even when the for PIM Join/Prune messages. This is the case even when the
connection is down. connection is down (there is no fallback to native Join/Prune
messages).
When PORT support is enabled, a router sends PIM Hello messages When PORT support is enabled, a router sends PIM Hello messages
announcing support for TCP and/or SCTP and also Connection IDs. It announcing support for TCP and/or SCTP and also Connection IDs. It
should be possible to configure a local Connection ID, and also to should be possible to configure a local Connection ID, and also to
see what PORT capabilities and Connection IDs PIM neighbors are see what PORT capabilities and Connection IDs PIM neighbors are
announcing. Based on these advertisements, pairs of PIM neighbors announcing. Based on these advertisements, pairs of PIM neighbors
will decide whether to try to establish a PORT connection. There will decide whether to try to establish a PORT connection. There
should be a way for an operator to check the current connection should be a way for an operator to check the current connection
state. Statistics on the number of PORT messages sent and received state. Statistics on the number of PORT messages sent and received
(including number of invalid messages) may also be helpful (including number of invalid messages) may also be helpful
skipping to change at page 28, line 5 skipping to change at page 29, line 5
For connection maintenance (see Section 4.2), it is recommended to For connection maintenance (see Section 4.2), it is recommended to
support Keep-Alive messages. It should be configurable whether to support Keep-Alive messages. It should be configurable whether to
send Keep-Alives. In that case, also wheter to use a Holdtime, and send Keep-Alives. In that case, also wheter to use a Holdtime, and
what Holdtime to use. what Holdtime to use.
There should be some way to alert an operator when PORT connections 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 are going down, or when there is a failure in establishing a PORT
connection. Also information like the number of connection failures, connection. Also information like the number of connection failures,
and how long the connection has been up or down, is useful. and how long the connection has been up or down, is useful.
10. Security Considerations 11. Security Considerations
There are several security issues related to the use of TCP or SCTP There are several security issues related to the use of TCP or SCTP
transports. The attacks would consist of sending packets with a transports. One can do off-path attacks sending packets with a
spoofed source address. Either establishing a connection, or spoofed source address. Either establishing a connection, or
injecting packets into an existing connnection. This might allow injecting packets into an existing connnection. This might allow
someone to send spoofed join/prune messages, and may also allow someone to send spoofed join/prune messages, and may also allow
someone to reset the connection. Mechanisms that help protect someone to reset the connection. Mechanisms that help protect
against this are discussed in Section 4.1). against this are discussed in Section 4.1).
For authentication one may for TCP use TCP-AO [RFC5925], and for SCTP For authentication one may for TCP use TCP-AO [RFC5925], and for SCTP
use Authenticated Chunks [RFC4895]. Also GTSM [RFC5082] can be used use Authenticated Chunks [RFC4895]. Also GTSM [RFC5082] can be used
to help prevent spoofing. to help prevent spoofing.
11. IANA Considerations 12. 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 an SCTP port
number for the use of PIM-Over-Reliable-Transport that has been number for the use of the pim-port service that has been assigned by
allocated by IANA. It also makes use of IANA PIM Hello Options IANA. It also makes use of IANA PIM Hello Options assignments that
allocations that should be made permanent. should be made permanent.
11.1. PORT Port Number 12.1. PORT Port Number
IANA has assigned a port number that is used as a destination port IANA has already assigned a port number that is used as a destination
for PORT TCP and SCTP transports. The assigned number is 8471. port for pim-port TCP and SCTP transports. The assigned number is
References to this document should be added to the Service Name and 8471. References to this document should be added to the Service
Transport Protocol Port Number Registry. Name and Transport Protocol Port Number Registry for pim-port.
11.2. PORT Hello Options 12.2. PORT Hello Options
In the Protocol Independent Multicast (PIM) Hello Options registry, In the Protocol Independent Multicast (PIM) Hello Options registry,
the following options are needed for PORT. the following options are needed for PORT.
Value Length Name Reference Value Length Name Reference
------- ---------- ----------------------- --------------- ------- ---------- ----------------------- ---------------
27 Variable PIM-over-TCP Capable this document 27 Variable PIM-over-TCP-Capable this document
28 Variable PIM-over-SCTP Capable this document 28 Variable PIM-over-SCTP-Capable this document
11.3. PORT Message Type Registry 12.3. PORT Message Type Registry
A registry for PORT message types is requested. The message type is 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 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 for assignments in the range 0 - 65531. This document defines two
PORT message types. Type 1, Join/Prune; and Type 2, Keep-alive. The PORT message types. Type 1, Join/Prune; and Type 2, Keep-alive. The
type range 65532 - 65535 is for experimental use [RFC3692]. type range 65532 - 65535 is for experimental use [RFC3692].
The initial content of the registry should be as follows: The initial content of the registry should be as follows:
Type Name Reference Type Name Reference
------------- ------------------------------- --------------- ------------- ------------------------------- ---------------
0 Reserved this document 0 Reserved this document
1 Join/Prune this document 1 Join/Prune this document
2 Keep-alive this document 2 Keep-alive this document
3-65531 Unassigned 3-65531 Unassigned
65532-65535 Experimental this document 65532-65535 Experimental this document
11.4. PORT Option Type Registry 12.4. PORT Option Type Registry
A registry for PORT option types is requested. The option type is a A registry for PORT option types is requested. The option type is a
16-bit integer, with values from 0 to 65535. Option types are 16-bit integer, with values from 0 to 65535. The type space is split
assigned by IANA, except the ranges 32764 - 32767 and 65532 - 65535 in two ranges, 0 - 32767 for Critical Options and 32768 - 65535 for
that are for experimental use [RFC3692]. An RFC is required for the Non-Critical Options. Option types are assigned by IANA, except the
IANA assignments. This document defines two PORT Option types. Type ranges 32764 - 32767 and 65532 - 65535 that are for experimental use
1, PIM IPv4 Join/Prune Message; and Type 2, PIM IPv6 Join/Prune [RFC3692]. An RFC is required for the IANA assignments. An RFC
Message. 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 Message; and Type 2, PIM IPv6 Join/Prune Message.
The initial content of the registry should be as follows: The initial content of the registry should be as follows:
Type Name Reference Type Name Reference
------------- ---------------------------------- --------------- ------------- ---------------------------------- ---------------
0 Reserved this document 0 Reserved this document
1 PIM IPv4 Join/Prune Message this document 1 PIM IPv4 Join/Prune this document
2 PIM IPv6 Join/Prune Message this document 2 PIM IPv6 Join/Prune this document
3-32763 Unassigned Critical Options 3-32763 Unassigned Critical Options
32764-32767 Experimental this document 32764-32767 Experimental this document
32768-65531 Unassigned Non-Critical Options 32768-65531 Unassigned Non-Critical Options
65532-65535 Experimental this document 65532-65535 Experimental this document
12. Contributors 13. 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.
13. Acknowledgments 14. 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, Dimitri Papadimitriou, Bharat Joshi, Rishabh Gulrajani, Thomas Morin, Dimitri Papadimitriou, Bharat Joshi, Rishabh
Parekh, Manav Bhatia and Pekka Savola. Parekh, Manav Bhatia, Pekka Savola, Tom Petch and Joe Touch.
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.
14. References 15. References
14.1. Normative References
[I-D.ietf-pim-hello-intid] 15.1. Normative References
Gulrajani, S. and S. Venaas, "An Interface ID Hello Option
for PIM", draft-ietf-pim-hello-intid-01 (work in
progress), June 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.
[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.
[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.
skipping to change at page 33, line 42 skipping to change at page 34, line 37
"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. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
14.2. Informative References [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", ADDRESS FAMILY NUMBERS htt [AFI] IANA, "Address Family Numbers", ADDRESS FAMILY NUMBERS htt
p://www.iana.org/assignments/address-family-numbers, p://www.iana.org/assignments/address-family-numbers,
February 2007. 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.
[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 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
cisco Systems cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
 End of changes. 51 change blocks. 
116 lines changed or deleted 186 lines changed or added

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