draft-ietf-pim-source-discovery-bsr-07.txt   draft-ietf-pim-source-discovery-bsr-08.txt 
Network Working Group IJ. Wijnands Network Working Group IJ. Wijnands
Internet-Draft S. Venaas Internet-Draft S. Venaas
Intended status: Experimental Cisco Systems, Inc. Intended status: Experimental Cisco Systems, Inc.
Expires: June 23, 2018 M. Brig Expires: July 20, 2018 M. Brig
Aegis BMD Program Office Aegis BMD Program Office
A. Jonasson A. Jonasson
Swedish Defence Material Administration (FMV) Swedish Defence Material Administration (FMV)
December 20, 2017 January 16, 2018
PIM flooding mechanism and source discovery PIM Flooding Mechanism and Source Discovery
draft-ietf-pim-source-discovery-bsr-07 draft-ietf-pim-source-discovery-bsr-08
Abstract Abstract
PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared
multicast packets from new sources. Once last hop routers receive trees to forward multicast packets from new sources. Once last hop
packets from a new source, they may join the Shortest Path Tree for routers receive packets from a new source, they may join the Shortest
the source for optimal forwarding. This draft defines a new Path Tree for the source for optimal forwarding. This draft defines
mechanism that provides a way to support PIM Sparse Mode (SM) without a new mechanism that provides a way to support PIM-SM without the
the need for PIM registers, RPs or shared trees. Multicast source need for PIM registers, RPs or shared trees. Multicast source
information is flooded throughout the multicast domain using a new information is flooded throughout the multicast domain using a new
generic PIM flooding mechanism. This allows last hop routers to generic PIM flooding mechanism. This allows last hop routers to
learn about new sources without receiving initial data packets. learn about new sources without receiving initial data packets.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 23, 2018. This Internet-Draft will expire on July 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Testing and deployment experiences . . . . . . . . . . . . . 4 2. Testing and Deployment Experiences . . . . . . . . . . . . . 4
3. A generic PIM flooding mechanism . . . . . . . . . . . . . . 4 3. A Generic PIM Flooding Mechanism . . . . . . . . . . . . . . 4
3.1. PFM message format . . . . . . . . . . . . . . . . . . . 6 3.1. PFM Message Format . . . . . . . . . . . . . . . . . . . 6
3.2. Administrative boundaries . . . . . . . . . . . . . . . . 7 3.2. Administrative Boundaries . . . . . . . . . . . . . . . . 7
3.3. Originating PFM messages . . . . . . . . . . . . . . . . 7 3.3. Originating PFM Messages . . . . . . . . . . . . . . . . 7
3.4. Processing PFM messages . . . . . . . . . . . . . . . . . 8 3.4. Processing PFM Messages . . . . . . . . . . . . . . . . . 8
3.4.1. Initial checks . . . . . . . . . . . . . . . . . . . 9 3.4.1. Initial Checks . . . . . . . . . . . . . . . . . . . 9
3.4.2. Processing and forwarding of PFM messages . . . . . . 9 3.4.2. Processing and Forwarding of PFM Messages . . . . . . 9
4. Distributing Source Group Mappings . . . . . . . . . . . . . 10 4. Distributing Source Group Mappings . . . . . . . . . . . . . 10
4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 10 4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 10
4.2. Originating Group Source Holdtime TLVs . . . . . . . . . 11 4.2. Originating Group Source Holdtime TLVs . . . . . . . . . 11
4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 11 4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 12
4.4. The first packets and bursty sources . . . . . . . . . . 12 4.4. The First Packets and Bursty Sources . . . . . . . . . . 12
4.5. Resiliency to network partitioning . . . . . . . . . . . 13 4.5. Resiliency to Network Partitioning . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared
forward multicast packets to Last Hop Routers (LHR). After the first trees to forward multicast packets to Last Hop Routers (LHR). After
packet is received by a LHR, the source of the multicast stream is the first packet is received by a LHR, the source of the multicast
learned and the Shortest Path Tree (SPT) can be joined. This draft stream is learned and the Shortest Path Tree (SPT) can be joined.
defines a new mechanism that provides a way to support PIM Sparse This draft defines a new mechanism that provides a way to support
Mode (SM) without the need for PIM registers, RPs or shared trees. PIM-SM without the need for PIM registers, RPs or shared trees.
Multicast source information is flooded throughout the multicast Multicast source information is flooded throughout the multicast
domain using a new generic PIM flooding mechanism. By removing the domain using a new generic PIM flooding mechanism. By removing the
need for RPs and shared trees, the PIM-SM procedures are simplified, need for RPs and shared trees, the PIM-SM procedures are simplified,
improving router operations, management and making the protocol more improving router operations, management and making the protocol more
robust. Also the data packets are only sent on the SPTs, providing robust. Also the data packets are only sent on the SPTs, providing
optimal forwarding. optimal forwarding.
This mechanism has some similarities to PIM Dense Mode (PIM-DM) with
its State-Refresh signaling [RFC3973], except that there is no
initial flooding of data packets for new sources. It provides the
traffic efficiency of PIM-SM, while being as easy to deploy as PIM-
DM. The downside is that it cannot provide forwarding of initial
packets from a new source, see Section 4.4. PIM-DM is very different
from PIM-SM and not as mature, Experimental vs Internet Standard, and
there are only a few implementations. The solution in this document
consists of a lightweight source discovery mechanism on top of the
Source-Specific Multicast (SSM) parts of PIM-SM. It is feasable to
implement only a subset of PIM-SM to provide SSM support, and in
addition implement the mechanism in this draft to offer a source
discovery mechanism for applications that do not provide their own
source discovery.
This document defines a generic flooding mechanism for distributing This document defines a generic flooding mechanism for distributing
information throughout a PIM domain. While the forwarding rules are information throughout a PIM domain. While the forwarding rules are
largely similar to Bootstrap Router mechanism (BSR) [RFC5059], any largely similar to Bootstrap Router mechanism (BSR) [RFC5059], any
router can originate information, and it allows for flooding of any router can originate information, and it allows for flooding of any
kind of information. Each message contains one or more pieces of kind of information. Each message contains one or more pieces of
information encoded as TLVs (type, length and value). This document information encoded as TLVs (type, length and value). This document
defines one TLV used for distributing information about active defines one TLV used for distributing information about active
multicast sources. Other documents may define additional TLVs. multicast sources. Other documents may define additional TLVs.
Note that this document is experimental. While the flooding Note that this document is experimental. While the flooding
skipping to change at page 3, line 32 skipping to change at page 3, line 47
and there are some concerns, mainly regarding potentially large and there are some concerns, mainly regarding potentially large
amounts of source states that need to be distributed. While there amounts of source states that need to be distributed. While there
has been some testing in the field, we need to learn more about the has been some testing in the field, we need to learn more about the
forwarding efficiency, both the amount of processing per router, and forwarding efficiency, both the amount of processing per router, and
propagation delay, and the amount of state that can be distributed. propagation delay, and the amount of state that can be distributed.
In particular, how many active sources one can support without In particular, how many active sources one can support without
consuming too many resources. There are also parameters that can be consuming too many resources. There are also parameters that can be
tuned regarding how frequently information is distributed, and it is tuned regarding how frequently information is distributed, and it is
not clear what parameters are useful for different types of networks. not clear what parameters are useful for different types of networks.
1.1. Conventions used in this document 1.1. Conventions Used in This Document
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
RP: Rendezvous Point RP: Rendezvous Point
BSR: Bootstrap Router BSR: Bootstrap Router
skipping to change at page 4, line 4 skipping to change at page 4, line 18
BSR: Bootstrap Router BSR: Bootstrap Router
RPF: Reverse Path Forwarding RPF: Reverse Path Forwarding
SPT: Shortest Path Tree SPT: Shortest Path Tree
FHR: First Hop Router, directly connected to the source FHR: First Hop Router, directly connected to the source
LHR: Last Hop Router, directly connected to the receiver LHR: Last Hop Router, directly connected to the receiver
PFM: PIM Flooding Mechanism PFM: PIM Flooding Mechanism
PFM-SA: PFM Source Announcement PFM-SD: PFM Source Discovery
SG Mapping: Multicast source group mapping SG Mapping: Multicast source group mapping
2. Testing and deployment experiences 2. Testing and Deployment Experiences
A prototype of this specification has been implemented and there has A prototype of this specification has been implemented and there has
been some limited testing in the field. The prototype was tested in been some limited testing in the field. The prototype was tested in
a network with low bandwidth radio links. The network has frequent a network with low bandwidth radio links. The network has frequent
topology changes, including frequest link or router failures. topology changes, including frequent link or router failures.
Previously existing mechanisms like PIM-SM and PIM-DM were tested. Previously existing mechanisms like PIM-SM and PIM-DM were tested.
With PIM-SM the existing RP election mechanisms were found to be too With PIM-SM the existing RP election mechanisms were found to be too
slow. With PIM-DM, issues were observed with new multicast sources slow. With PIM-DM, issues were observed with new multicast sources
starving low bandwidth links even when there are no receivers, in starving low bandwidth links even when there are no receivers, in
some cases such that there was no bandwidth left for prune message. some cases such that there was no bandwidth left for prune messages.
For the PFM-SA prototype tests, all routers were configured to send For the PFM-SD prototype tests, all routers were configured to send
PFM-SA for directly connected source and to cache received PFM-SD for directly connected source and to cache received
announcements. Applications such as SIP with multicast subscriber announcements. Applications such as SIP with multicast subscriber
discovery, multicast voice conferencing, position tracking and NTP discovery, multicast voice conferencing, position tracking and NTP
were successfully tested. The tests went quite well. Packets were were successfully tested. The tests went quite well. Packets were
rerouted as needed and there were no unnecessary forwarding of rerouted as needed and there were no unnecessary forwarding of
packets. Ease of configuration was seen as a plus. packets. Ease of configuration was seen as a plus.
3. A generic PIM flooding mechanism 3. A Generic PIM Flooding Mechanism
The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used
mechanism for distributing dynamic Group to RP mappings in PIM. It mechanism for distributing dynamic Group to RP mappings in PIM. It
is responsible for flooding information about such mappings is responsible for flooding information about such mappings
throughout a PIM domain, so that all routers in the domain can have throughout a PIM domain, so that all routers in the domain can have
the same information. BSR as defined, is only able to distribute the same information. BSR as defined, is only able to distribute
Group to RP mappings. This document defines a more generic mechanism Group to RP mappings. This document defines a more generic mechanism
that can flood any kind of information. Administrative boundaries that can flood any kind of information. Administrative boundaries,
Section 3.2 may be configured to limit to which parts of a network see Section 3.2, may be configured to limit to which parts of a
the information is flooded. network the information is flooded.
The forwarding rules are identical to BSR, except that one can The forwarding rules are identical to BSR, except that one can
control whether routers should forward unsupported data types. For control whether routers should forward unsupported data types. For
some types of information it is quite useful that it can be some types of information it is quite useful that it can be
distributed without all routers having to support the particular distributed without all routers having to support the particular
type, while there may also be types where it is necessary for every type, while there may also be types where it is necessary for every
single router to support it. The mechanism includes an originator single router to support it. The mechanism includes an originator
address which is used for RPF checking to restrict the flooding, and address which is used for RPF checking to restrict the flooding, and
prevent loops, just like BSR. Like BSR, messages are forwarded hop prevent loops, just like BSR. Like BSR, messages are forwarded hop
by hop. Note that there is no equivalent to the BSR election by hop. Note that there is no equivalent to the BSR election
mechanism;, there can be multiple originators. This mechanism is mechanism;, there can be multiple originators. This mechanism is
named the PIM Flooding Mechanism (PFM). named the PIM Flooding Mechanism (PFM).
3.1. PFM message format 3.1. PFM Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum | |PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded-Unicast format) | | Originator Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 1 | Length 1 | |T| Type 1 | Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 | | Value 1 |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
| Type n | Length n | |T| Type n | Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value n | | Value n |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved and Checksum: As specified in [RFC7761]. PIM Version, Reserved and Checksum: As specified in [RFC7761].
Type: PIM Message Type. Value (pending IANA) for a PFM message. Type: PIM Message Type. Value (pending IANA) for a PFM message.
[N]o-Forward bit: When set, this bit means that the PFM message is [N]o-Forward bit: When set, this bit means that the PFM message is
not to be forwarded. This bit is defined to prevent Bootstrap not to be forwarded. This bit is defined to prevent Bootstrap
message forwarding in [RFC5059]. message forwarding in [RFC5059].
Originator Address: The address of the router that originated the Originator Address: The address of the router that originated the
message. This can be any address assigned to the originating message. This can be any address assigned to the originating
router, but MUST be routable in the domain to allow successful router, but MUST be routable in the domain to allow successful
forwarding. The format for this address is given in the Encoded- forwarding. The format for this address is given in the Encoded-
Unicast address in [RFC7761]. Unicast address in [RFC7761].
[T]ransitive bit: Each TLV in the message includes a bit called the
Transitive bit that controls whether the TLV is forwarded by
routers that do not support the given type. See Section 3.4.2.
Type 1..n: A message contains one or more TLVs, in this case n Type 1..n: A message contains one or more TLVs, in this case n
TLVs. The Type specifies what kind of information is in the TLVs. The Type specifies what kind of information is in the
Value. The type range is from 0 to 65535. A TLV with a type in Value. The type range is from 0 to 32767 (15 bits).
the range from 32768 to 65535 is never to be forwarded by an
implementation not supporting the type, see Section 3.4.2.
Length 1..n: The length of the the value field in octets. Length 1..n: The length of the the value field in octets.
Value 1..n: The value associated with the type and of the specified Value 1..n: The value associated with the type and of the specified
length. length.
3.2. Administrative boundaries 3.2. Administrative Boundaries
PFM messages are generally forwarded hop by hop to all PIM routers. PFM messages are generally forwarded hop by hop to all PIM routers.
However, similar to BSR, one may configure administrative boundaries However, similar to BSR, one may configure administrative boundaries
to limit the information to certain domains or parts of the network. to limit the information to certain domains or parts of the network.
Implementations MUST have a way of defining a set of interfaces on a Implementations MUST have a way of defining a set of interfaces on a
router as administrative boundaries for all PFM messages, or router as administrative boundaries for all PFM messages, or
optionally for certain TLVs, allowing for different boundaries for optionally for certain TLVs, allowing for different boundaries for
different TLVs. Usually one wants boundaries to be bidirectional, different TLVs. Usually one wants boundaries to be bidirectional,
but an implementation MAY also provide unidirectional boundaries. but an implementation MAY also provide unidirectional boundaries.
When forwarding a message, a router MUST NOT send it out an interface When forwarding a message, a router MUST NOT send it out an interface
skipping to change at page 7, line 33 skipping to change at page 7, line 36
incoming boundary, including bidirectional boundary, for all PFM incoming boundary, including bidirectional boundary, for all PFM
messages. If the interface is an incoming boundary for certain TLVs, messages. If the interface is an incoming boundary for certain TLVs,
the router MUST ignore all boundary TLVs. If all the TLVs in the the router MUST ignore all boundary TLVs. If all the TLVs in the
message are boundary TLVs, then the message is effectively ignored. message are boundary TLVs, then the message is effectively ignored.
Note that when forwarding an incoming message, the boundary is Note that when forwarding an incoming message, the boundary is
applied before forwarding. If the message was discarded or all the applied before forwarding. If the message was discarded or all the
TLVs were ignored, then no message is forwarded. When a message is TLVs were ignored, then no message is forwarded. When a message is
forwarded, it MUST NOT contain any TLVs for which the incoming forwarded, it MUST NOT contain any TLVs for which the incoming
interface is an incoming, or bidirectional, boundary. interface is an incoming, or bidirectional, boundary.
3.3. Originating PFM messages 3.3. Originating PFM Messages
A router originates a PFM message when it needs to distribute A router originates a PFM message when it needs to distribute
information using a PFM message to other routers in the network. information using a PFM message to other routers in the network.
When a message is originated depends on what information is When a message is originated depends on what information is
distributed. For instance this document defines a TLV to distribute distributed. For instance this document defines a TLV to distribute
information about active sources. When a router has a new active information about active sources. When a router has a new active
source, a PFM message should be sent as soon as possible. Hence a source, a PFM message should be sent as soon as possible. Hence a
PFM message should be sent every time there is a new active source. PFM message should be sent every time there is a new active source.
However, the TLV also contains a holdtime and PFM messages need to be However, the TLV also contains a holdtime and PFM messages need to be
sent periodically. Generally speaking, a PFM message would typically sent periodically. Generally speaking, a PFM message would typically
skipping to change at page 8, line 33 skipping to change at page 8, line 36
be received by all routers in a domain, all the routers need to have be received by all routers in a domain, all the routers need to have
a route for this address due to the RPF based forwarding. Hence an a route for this address due to the RPF based forwarding. Hence an
administrator needs to be careful which address to choose. When this administrator needs to be careful which address to choose. When this
is not configured, an implementation MUST NOT use a link-local is not configured, an implementation MUST NOT use a link-local
address. It is RECOMMENDED to use an address of a virtual interface address. It is RECOMMENDED to use an address of a virtual interface
such that the originator can remain unchanged and routable such that the originator can remain unchanged and routable
independent of which physical interfaces or links may go down. independent of which physical interfaces or links may go down.
The No-Forward bit MUST NOT be set, except for the case when a router The No-Forward bit MUST NOT be set, except for the case when a router
receives a PIM Hello from a new neighbor, or a PIM Hello with a new receives a PIM Hello from a new neighbor, or a PIM Hello with a new
GenID is received from an existing neighbor. In that case an Generation Identifier, defined in [RFC7761], is received from an
implementation MAY send PFM messages containing relevant information existing neighbor. In that case an implementation MAY send PFM
so that the neighbor can quickly get the correct state. The messages containing relevant information so that the neighbor can
definition of the different PFM message TLVs need to specify what, if quickly get the correct state. The definition of the different PFM
anything, needs to be sent in this case. If such a PFM message is message TLVs need to specify what, if anything, needs to be sent in
sent, the No-Forward bit MUST be set, and the message must be sent this case. If such a PFM message is sent, the No-Forward bit MUST be
within 60 seconds after the neighbor state change. The processing set, and the message must be sent within 60 seconds after the
rules for PFM messages will ensure that any other neighbors on the neighbor state change. The processing rules for PFM messages will
same link ignores the message. ensure that any other neighbors on the same link ignores the message.
This behavior and the choice of 60 seconds is similar to what is
defined for the No-Forward bit in [RFC5059].
3.4. Processing PFM messages 3.4. Processing PFM Messages
A router that receives a PFM message MUST perform the initial checks A router that receives a PFM message MUST perform the initial checks
specified here. If the checks fail, the message MUST be dropped. An specified here. If the checks fail, the message MUST be dropped. An
error MAY be logged, but otherwise the message MUST be dropped error MAY be logged, but otherwise the message MUST be dropped
silently. If the checks pass, the contents is processed according to silently. If the checks pass, the contents is processed according to
the processing rules of the included TLVs. the processing rules of the included TLVs.
3.4.1. Initial checks 3.4.1. Initial Checks
In order to do further processing, a message MUST meet the following In order to do further processing, a message MUST meet the following
requirements. The message MUST be from a directly connected PIM requirements. The message MUST be from a directly connected PIM
neighbor, the destination address MUST be ALL-PIM-ROUTERS. Also, the neighbor, the destination address MUST be ALL-PIM-ROUTERS. Also, the
interface MUST NOT be an incoming, nor bidirectional, administrative interface MUST NOT be an incoming, nor bidirectional, administrative
boundary for PFM messages Section 3.2. If No-Forward is not set, the boundary for PFM messages, see Section 3.2. If No-Forward is not
message MUST be from the RPF neighbor of the originator address. If set, the message MUST be from the RPF neighbor of the originator
No-Forward is set, this system, the router doing these checks, MUST address. If No-Forward is set, this system, the router doing these
have restarted within 60 seconds. In pseudo-code the algorithm is as checks, MUST have enabled the PIM protocol within the last 60
follows: seconds. See Section 3.3 for details. In pseudo-code the algorithm
is as follows:
if ((DirectlyConnected(PFM.src_ip_address) == FALSE) OR if ((DirectlyConnected(PFM.src_ip_address) == FALSE) OR
(PFM.src_ip_address is not a PIM neighbor) OR (PFM.src_ip_address is not a PIM neighbor) OR
(PFM.dst_ip_address != ALL-PIM-ROUTERS) OR (PFM.dst_ip_address != ALL-PIM-ROUTERS) OR
(Incoming interface is admin boundary for PFM)) { (Incoming interface is admin boundary for PFM)) {
drop the message silently, optionally log error.
}
if (PFM.no_forward_bit == 0) {
if (PFM.src_ip_address !=
RPF_neighbor(PFM.originator_ip_address)) {
drop the message silently, optionally log error. drop the message silently, optionally log error.
} }
if (PFM.no_forward_bit == 0) { } else if (more than 60 seconds elapsed since PIM enabled)) {
if (PFM.src_ip_address != drop the message silently, optionally log error.
RPF_neighbor(PFM.originator_ip_address)) { }
drop the message silently, optionally log error.
}
} else if (more than 60 seconds elapsed since startup)) {
drop the message silently, optionally log error.
}
Note that src_ip_address is the source address in the IP header of Note that src_ip_address is the source address in the IP header of
the PFM message. Originator is the originator field inside the PFM the PFM message. Originator is the originator field inside the PFM
message, and is the router that originated the message. When the message, and is the router that originated the message. When the
message is forwarded hop by hop, the originator address never message is forwarded hop by hop, the originator address never
changes, while the source address will be an address belonging to the changes, while the source address will be an address belonging to the
router that last forwarded the message. router that last forwarded the message.
3.4.2. Processing and forwarding of PFM messages 3.4.2. Processing and Forwarding of PFM Messages
When the message is received, the initial checks above must be When the message is received, the initial checks above must be
performed. If it passes the checks, then for each included TLV, performed. If it passes the checks, then for each included TLV,
perform processing according to the specification for that TLV. perform processing according to the specification for that TLV.
After processing, the messsage is forwarded. Unless otherwise After processing, the messsage is forwarded. Some TLVs may be
specified by the type specification, the TLVs in the forwarded omitted or modified in the forwarded message. This depends on
message are identical to the TLVs in the received message. However, administrative boundaries, see Section 3.2, the type specification
if the most significant bit in the type field is set (the type value and the setting of the Transitive bit for the TLV. If a router
is larger than 32767) and this system does not support the type, then supports the type, then the TLV is forwarded with no changes unless
that particular type should be omitted from the forwarded messages. otherwise specified by the type specification. A router not
The message is forwarded out of all interfaces with PIM neighbors supporting the given type MUST include the TLV in the forwarded
(including the interface it was received on). message if and only if the Transitive bit is set. Whether a router
supports the type or not, the value of the Transitive bit MUST be
preserved if the TLV is included in the forwarded message. The
message is forwarded out of all interfaces with PIM neighbors
(including the interface it was received on). As specified in
Section 3.2, if an interface is an outgoing boundary for any TLVs,
the message MUST NOT be sent out the interface if it is an outgoing
boundary for all the TLVs in the message. Otherwise the router MUST
remove any outgoing boundary TLVs of the interface from the message
and send the message out that interface with the remaining TLVs.
4. Distributing Source Group Mappings 4. Distributing Source Group Mappings
The generic flooding mechanism (PFM) defined in the previous section The generic flooding mechanism (PFM) defined in the previous section
can be used for distributing source group mappings about active can be used for distributing source group mappings about active
multicast sources throughout a PIM domain. A Group Source Holtime multicast sources throughout a PIM domain. A Group Source Holdtime
(GSH) TLV is defined for this purpose. (GSH) TLV is defined for this purpose.
4.1. Group Source Holdtime TLV 4.1. Group Source Holdtime TLV
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 = 0 | Length | |1| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) | | Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime | | Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) | | Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) | | Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) | | Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: This TLV has type 0. 1: The Transitive bit is set to 1. This means that this type will
be forwarded even if a router does not support it. See
Section 3.4.2.
Type: This TLV has type 1.
Length: The length of the value in octets. Length: The length of the value in octets.
Group Address: The group that sources are to be announced for. The Group Address: The group that sources are to be announced for. The
format for this address is given in the Encoded-Group format in format for this address is given in the Encoded-Group format in
[RFC7761]. [RFC7761].
Src Count: How many unicast encoded sources address encodings Src Count: The number of source addresses that are included.
follow.
Src Holdtime: The Holdtime (in seconds) for the corresponding Src Holdtime: The Holdtime (in seconds) for the included source(s).
source(s).
Src Address: The source address for the corresponding group. The Src Address: The source address for the corresponding group. The
format for these addresses is given in the Encoded-Unicast address format for these addresses is given in the Encoded-Unicast address
in [RFC7761]. in [RFC7761].
4.2. Originating Group Source Holdtime TLVs 4.2. Originating Group Source Holdtime TLVs
A PFM message MAY contain one or more Group Source Holdtime (GSH) A PFM message MAY contain one or more Group Source Holdtime (GSH)
TLVs. This is used to flood information about active multicast TLVs. This is used to flood information about active multicast
sources. Each FHR that is directly connected to an active multicast sources. Each FHR that is directly connected to an active multicast
skipping to change at page 11, line 23 skipping to change at page 11, line 37
registering process described in [RFC7761]. When a FHR has decided registering process described in [RFC7761]. When a FHR has decided
that a register needs to be sent per [RFC7761], the SG is not that a register needs to be sent per [RFC7761], the SG is not
registered via the PIM SM register procedures, but the SG mapping is registered via the PIM SM register procedures, but the SG mapping is
included in an GSH TLV in a PFM message. Note, only the SG mapping included in an GSH TLV in a PFM message. Note, only the SG mapping
is distributed in the message, not the entire packet as would have is distributed in the message, not the entire packet as would have
been done with a PIM register. The PFM messages containing the GSH been done with a PIM register. The PFM messages containing the GSH
TLV are periodically sent for as long as the multicast source is TLV are periodically sent for as long as the multicast source is
active, similar to how PIM registers are periodically sent. The active, similar to how PIM registers are periodically sent. The
default announcement period is 60 seconds, which means that as long default announcement period is 60 seconds, which means that as long
as the source is active, it is included in a PFM message originated as the source is active, it is included in a PFM message originated
every 60 seconds. The holdtime for the source is by default 210 every 60 seconds. The holdtime for the source MUST be either zero,
seconds. Other values MAY be configured, but the holdtime MUST be or larger than the announcement period. It is RECOMMENDED to be 3.5
either zero, or larger than the announcement period. It is times the announcement period. The default holdtime is 210 seconds,
RECOMMENDED to be 3.5 times the announcement period. A source MAY be other values MAY be configured. A source MAY be announced with a
announced with a holdtime of zero to indicate that the source is no holdtime of zero to indicate that the source is no longer active.
longer active.
If an implementation supports originating GSH TLVs with different If an implementation supports originating GSH TLVs with different
holdtimes for different sources, it can if needed send multiple TLVs holdtimes for different sources, it can if needed send multiple TLVs
with the same group address. Due to the format, all the sources in with the same group address. Due to the format, all the sources in
the same TLV have the same holdtime. the same TLV have the same holdtime.
When a new source is detected, an implementation MAY send a PFM When a new source is detected, an implementation MAY send a PFM
message containing just that particular source. However, it MAY also message containing just that particular source. However, it MAY also
include information about other sources that were just detected, so include information about other sources that were just detected, so
sources that are scheduled for periodic announcement later, or other sources that are scheduled for periodic announcement later, or other
types of information. See Section 3.3 for details. types of information. See Section 3.3 for details.
When a new PIM neighbor is detected, or an existing neighbor changes When a new PIM neighbor is detected, or an existing neighbor changes
GenID, an implementation MAY send a triggered PFM message containing Generation Identifier, an implementation MAY send a triggered PFM
GSH TLVs for any Source Group mappings it has learned by receiving message containing GSH TLVs for any Source Group mappings it has
PFM GSH TLVs as well as any active directly connected sources. See learned by receiving PFM GSH TLVs as well as any active directly
Section 3.3 for further details. connected sources. See Section 3.3 for further details.
4.3. Processing GSH TLVs 4.3. Processing GSH TLVs
A router that receives a PFM message containing GSH TLVs MUST parse A router that receives a PFM message containing GSH TLVs MUST parse
the GSH TLVs and store each of the GSH TLVs as SG mappings with a the GSH TLVs and store each of the GSH TLVs as SG mappings with a
holdtimer started with the advertised holdtime, unless the holdtimer started with the advertised holdtime, unless the
implementation specifically does not support GSH TLVs, the router is implementation specifically does not support GSH TLVs, the router is
configured to ignore GSH TLVs in general, or to ignore GSH TLVs for configured to ignore GSH TLVs in general, or to ignore GSH TLVs for
certain sources or groups. In particular, an administrator might certain sources or groups. In particular, an administrator might
configure a router to not process GSH TLVs if the router is known to configure a router to not process GSH TLVs if the router is known to
skipping to change at page 12, line 27 skipping to change at page 12, line 40
source, so it may be desirable to allow the state to time out rather source, so it may be desirable to allow the state to time out rather
than sending a prune. than sending a prune.
Note that a holdtime of zero has a special meaning. It is to be Note that a holdtime of zero has a special meaning. It is to be
treated as if the source just expired, and state to be removed. treated as if the source just expired, and state to be removed.
Source information MUST NOT be removed due to the source being Source information MUST NOT be removed due to the source being
omitted in a message. For instance, if there is a large number of omitted in a message. For instance, if there is a large number of
sources for a group, there may be multiple PFM messages, each message sources for a group, there may be multiple PFM messages, each message
containing a different list of sources for the group. containing a different list of sources for the group.
4.4. The first packets and bursty sources 4.4. The First Packets and Bursty Sources
The PIM register procedure is designed to deliver Multicast packets The PIM register procedure is designed to deliver Multicast packets
to the RP in the absence of a Shortest Path Tree (SPT) from the RP to to the RP in the absence of a Shortest Path Tree (SPT) from the RP to
the source. The register packets received on the RP are decapsulated the source. The register packets received on the RP are decapsulated
and forwarded down the shared tree to the LHRs. As soon as an SPT is and forwarded down the shared tree to the LHRs. As soon as an SPT is
built, multicast packets would flow natively over the SPT to the RP built, multicast packets would flow natively over the SPT to the RP
or LHR and the register process would stop. The PIM register process or LHR and the register process would stop. The PIM register process
ensures packet delivery until an SPT is in place reaching the FHR. ensures packet delivery until an SPT is in place reaching the FHR.
If the packets were not unicast encapsulated to the RP they would be If the packets were not unicast encapsulated to the RP they would be
dropped by the FHR until the SPT is setup. This functionality is dropped by the FHR until the SPT is setup. This functionality is
skipping to change at page 13, line 13 skipping to change at page 13, line 25
sensitive for the delivery of the first packet this solution would sensitive for the delivery of the first packet this solution would
not be very applicable. This solution is mostly useful for not be very applicable. This solution is mostly useful for
applications that don't have strong dependency on the initial applications that don't have strong dependency on the initial
packet(s) and have a fairly constant data rate, like video packet(s) and have a fairly constant data rate, like video
distribution for example. For applications with strong dependency on distribution for example. For applications with strong dependency on
the initial packet(s) using PIM Bidir [RFC5015] or SSM [RFC4607] is the initial packet(s) using PIM Bidir [RFC5015] or SSM [RFC4607] is
recommended. The protocol operations are much simpler compared to recommended. The protocol operations are much simpler compared to
PIM SM, it will cause less churn in the network and both guarantee PIM SM, it will cause less churn in the network and both guarantee
best effort delivery for the initial packet(s). best effort delivery for the initial packet(s).
4.5. Resiliency to network partitioning 4.5. Resiliency to Network Partitioning
In a PIM SM deployment where the network becomes partitioned, due to In a PIM SM deployment where the network becomes partitioned, due to
link or node failure, it is possible that the RP becomes unreachable link or node failure, it is possible that the RP becomes unreachable
to a certain part of the network. New sources that become active in to a certain part of the network. New sources that become active in
that partition will not be able to register to the RP and receivers that partition will not be able to register to the RP and receivers
within that partition are not able to receive the traffic. Ideally within that partition are not able to receive the traffic. Ideally
you would want to have a candidate RP in each partition, but you you would want to have a candidate RP in each partition, but you
never know in advance which routers will form a partitioned network. never know in advance which routers will form a partitioned network.
In order to be fully resilient, each router in the network may end up In order to be fully resilient, each router in the network may end up
being a candidate RP. This would increase the operational complexity being a candidate RP. This would increase the operational complexity
skipping to change at page 14, line 11 skipping to change at page 14, line 26
though, the PFM messages are flooded within the network, and by though, the PFM messages are flooded within the network, and by
forging a large number of PFM messages one might stress all the forging a large number of PFM messages one might stress all the
routers in the network. routers in the network.
If an attacker can forge PFM messages, then such messages may contain If an attacker can forge PFM messages, then such messages may contain
arbitrary GSH TLVs. An issue here is that an attacker might send arbitrary GSH TLVs. An issue here is that an attacker might send
such TLVs for a huge amount of sources, potentially causing every such TLVs for a huge amount of sources, potentially causing every
router in the network to store huge amounts of source state. Also, router in the network to store huge amounts of source state. Also,
if there is receiver interest for the groups specified in the GSH if there is receiver interest for the groups specified in the GSH
TLVs, routers with directly connected receivers will build Shortest TLVs, routers with directly connected receivers will build Shortest
Path Trees for the announced sources, even if the sources are Path Trees for the announced sources, even if the sources are not
actually active. Building such trees will consume additional actually active. Building such trees will consume additional
resources on routers that the trees pass through. resources on routers that the trees pass through.
6. IANA considerations PIM-SM link-local messages can be authenticated using IPsec, see
[RFC7761] section 6.3 and [RFC5796]. Since PFM messages are link-
local messages sent hop by hop, a link-local PFM message can be
authenticated using IPsec such that a router can verify that a
message was sent by a trusted neighbor and has not been modified.
However, to verify that a received message contains correct
information announced by the originator specified in the message, one
will have to trust every router on the path from the originator and
that each router has authenticated the received message.
6. IANA Considerations
This document requires the assignment of a new PIM message type for This document requires the assignment of a new PIM message type for
the PIM Flooding Mechanism (PFM). IANA is also requested to create a the PIM Flooding Mechanism (PFM) with the name "PIM Flooding
registry for PFM TLVs, with type 0 assigned to the "Source Group Mechanism". IANA is also requested to create a registry for PFM TLVs
Holdtime" TLV. Values in the range from 1 to 65535 are "Unassigned". called "PIM Flooding Mechanism Message Types". Assignments for the
Assignments for the registry are to be made according to the policy registry are to be made according to the policy "IETF Review" as
"IETF Review" as defined in [RFC8126]. defined in [RFC8126]. The initial content of the registry should be:
Type Name Reference
--------------------------------------------------
0 Reserved [this document]
1 Source Group Holdtime [this document]
2-32767 Unassigned
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Arjen Boers for contributing to the The authors would like to thank Arjen Boers for contributing to the
initial idea, and Yiqun Cai and Dino Farinacci for their comments on initial idea, and Stewart Bryant, Yiqun Cai, Toerless Eckert, Dino
the draft. Farinacci, Alvaro Retana and Liang Xia for their very helpful
comments on the draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent "Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January
2008, <https://www.rfc-editor.org/info/rfc5059>. 2008, <https://www.rfc-editor.org/info/rfc5059>.
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
Confidentiality in Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 5796,
DOI 10.17487/RFC5796, March 2010,
<https://www.rfc-editor.org/info/rfc5796>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
8.2. Informative References 8.2. Informative References
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005, <https://www.rfc-editor.org/info/rfc3973>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>. <https://www.rfc-editor.org/info/rfc4607>.
[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, DOI 10.17487/RFC5015, October 2007, PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>. <https://www.rfc-editor.org/info/rfc5015>.
Authors' Addresses Authors' Addresses
 End of changes. 49 change blocks. 
123 lines changed or deleted 182 lines changed or added

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