draft-ietf-pim-source-discovery-bsr-04.txt   draft-ietf-pim-source-discovery-bsr-05.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: September 18, 2016 M. Brig Expires: May 4, 2017 M. Brig
Aegis BMD Program Office Aegis BMD Program Office
A. Jonasson A. Jonasson
Swedish Defence Material Administration (FMV) Swedish Defence Material Administration (FMV)
March 17, 2016 October 31, 2016
PIM flooding mechanism and source discovery PIM flooding mechanism and source discovery
draft-ietf-pim-source-discovery-bsr-04 draft-ietf-pim-source-discovery-bsr-05
Abstract Abstract
PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward
multicast packets from new sources. Once last hop routers receive multicast packets from new sources. Once last hop routers receive
packets from a new source, they may join the Shortest Path Tree for packets from a new source, they may join the Shortest Path Tree for
the source for optimal forwarding. This draft defines a new protcol the source for optimal forwarding. This draft defines a new protcol
that provides a way to support PIM Sparse Mode (SM) without the need that provides a way to support PIM Sparse Mode (SM) without the need
for PIM registers, RPs or shared trees. Multicast source information for PIM registers, RPs or shared trees. Multicast source information
is flooded throughout the multicast domain using a new generic PIM is flooded throughout the multicast domain using a new generic PIM
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 September 18, 2016. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . 3
2. Testing and deployment experiences . . . . . . . . . . . . . 3 2. Testing and deployment experiences . . . . . . . . . . . . . 3
3. A generic PIM flooding mechanism . . . . . . . . . . . . . . 4 3. A generic PIM flooding mechanism . . . . . . . . . . . . . . 4
3.1. PFP message format . . . . . . . . . . . . . . . . . . . 4 3.1. PFM message format . . . . . . . . . . . . . . . . . . . 4
3.2. Processing PFP messages . . . . . . . . . . . . . . . . . 6 3.2. Processing PFM messages . . . . . . . . . . . . . . . . . 5
3.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 6 3.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 5
3.2.2. Processing messages of supported PFP type . . . . . . 7 3.2.2. Processing and forwarding of PFM messages . . . . . . 6
3.2.3. Processing messages of unsupported PFP type . . . . . 7 4. Distributing Source to Group Mappings . . . . . . . . . . . . 6
4. Distributing Source to Group Mappings . . . . . . . . . . . . 7 4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 6
4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 8 4.2. Originating PFM messages . . . . . . . . . . . . . . . . 7
4.2. Originating SG messages . . . . . . . . . . . . . . . . . 8 4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 8
4.3. Processing SG messages . . . . . . . . . . . . . . . . . 9 4.4. The first packets and bursty sources . . . . . . . . . . 8
4.4. The first packets and bursty sources . . . . . . . . . . 9 4.5. Resiliency to network partitioning . . . . . . . . . . . 9
4.5. Resiliency to network partitioning . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to
forward multicast packets to Last Hop Routers (LHR). After the first forward multicast packets to Last Hop Routers (LHR). After the first
packet is received by a LHR, the source of the multicast stream is packet is received by a LHR, the source of the multicast stream is
learned and the Shortest Path Tree (SPT) can be joined. This draft learned and the Shortest Path Tree (SPT) can be joined. This draft
defines a new protocol that provides a way to support PIM Sparse Mode defines a new mechanism that provides a way to support PIM Sparse
(SM) without the need for PIM registers, RPs or shared trees. Mode (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. This mechanism is domain using a new generic PIM flooding mechanism. This mechanism is
defined in this document, and is modeled after the Bootstrap Router defined in this document, and is modeled after the Bootstrap Router
protocol [RFC5059]. By removing the need for RPs and shared trees, mechanism [RFC5059]. By removing the need for RPs and shared trees,
the PIM-SM procedures are simplified, improving router operations, the PIM-SM procedures are simplified, improving router operations,
management and making the protocol more robust. Also the data management and making the protocol more robust. Also the data
packets are only sent on the SPTs, providing optimal forwarding. packets are only sent on the SPTs, providing optimal forwarding.
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].
skipping to change at page 3, line 28 skipping to change at page 3, line 27
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.
SG Mapping: Multicast source to group mapping. PFM: PIM Flooding Mechanism.
SG Message: A PIM message containing SG Mappings. PFM-SA: PFM Source Announcement.
SG Mapping: Multicast source to 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. In this network with a network with low bandwidth radio links. In this network with
frequent topology changes and link or router failures PIM-SM with RP frequent topology changes and link or router failures, PIM-SM with RP
election is found to be too slow. With PIM-DM issues were observed election is found to be too slow. With PIM-DM, issues were observed
with new multicast sources starving low bandwidth links even when with new multicast sources starving low bandwidth links even when
there are no receivers, in some cases such that there were no there are no receivers, in some cases such that there was no
bandwidth left for prune message. For the tests, all routers were bandwidth left for prune message. For the tests, all routers were
configured to send PFP-SA for directly connected source and to cache configured to send PFM-SA for directly connected source and to cache
received announcements. Applications such as SIP with multicast received announcements. Applications such as SIP with multicast
subscriber discovery, multicast voice conferencing, position tracking subscriber discovery, multicast voice conferencing, position tracking
and NTP were successfully tested. The tests went quite well. and NTP were successfully tested. The tests went quite well.
Packets were rerouted as needed and there were no unnecessary Packets were rerouted as needed and there were no unnecessary
forwarding of packets. Ease of configuration was seen as a plus. forwarding of packets. Ease of configuration was seen as a plus.
3. A generic PIM flooding mechanism 3. A generic PIM flooding mechanism
The Bootstrap Router protocol (BSR) [RFC5059] is a commonly used The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used
protocol for distributing dynamic Group to RP mappings in PIM. It is mechanism for distributing dynamic Group to RP mappings in PIM. It
responsible for flooding information about such mappings throughout a is responsible for flooding information about such mappings
PIM domain, so that all routers in the domain can have the same throughout a PIM domain, so that all routers in the domain can have
information. BSR as defined, is only able to distribute Group to RP the same information. BSR as defined, is only able to distribute
mappings. We are defining a more generic mechanism that can flood Group to RP mappings. We are defining a more generic mechanism that
any kind of information throughout a PIM domain. It is not can flood any kind of information throughout a PIM domain. It is not
necessarily a domain though, it depends on the administrative necessarily a domain though, it depends on the administrative
boundaries being configured. The forwarding rules are identical to boundaries being configured. The forwarding rules are identical to
BSR, except that there is no BSR election and that one can control BSR, except that there is no BSR election and that one can control
whether routers should forward messages of unsupported types. For whether routers should forward unsupported data types. For some
some types of information it is quite useful that it can be types of information it is quite useful that it can be distributed
distributed without all routers having to support the particular without all routers having to support the particular type, while
type, while there may also be types where it is necessary for every there may also be types where it is necessary for every single router
single router to support it. The protocol includes an originator to support it. The mechanism includes an originator address which is
address which is used for RPF checking to restrict the flooding, just used for RPF checking to restrict the flooding, and prevent loops,
like BSR. Just like BSR it is also sent hop by hop. Note that there just like BSR. Just like BSR it is also sent hop by hop. Note that
is no built in election mechanism as in BSR, so there can be multiple there is no built in election mechanism as in BSR, so there can be
originators. It is still possible to add such an election mechanism multiple originators. We call this mechanism the PIM Flooding
on a type by type bases if this protocol is used in scenarios where Mechanism (PFM).
this is desirable. We include a type field, which can allow
boundaries to be defined, and election to take place, independently 3.1. PFM message format
per type. We call this protocol the PIM Flooding Protocol (PFP).
3.1. PFP 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PFP Type | Reserved |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 1 | Length 1 | | Type 1 | Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 | | Value 1 |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
| Type n | Length n | | Type n | Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value n | | Value n |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version: Reserved, Checksum Described in [RFC7761]. PIM Version: Reserved, Checksum Described in [RFC7761].
Type: PIM Message Type. Value (pending IANA) for a PFP message. Type: PIM Message Type. Value (pending IANA) for a PFM message.
[N]o-Forward bit: When set, this bit means that the PFP message is [N]o-Forward bit: When set, this bit means that the PFM message is
not to be forwarded. This is irrespective of the value of the not to be forwarded.
Unsupported-No-Forwarding bit defined below.
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 (just like BSR address). The format for this address forwarding. The format for this address is given in the Encoded-
is given in the Encoded-Unicast address in [RFC7761]. Unicast address in [RFC7761].
PFP Type: There may be different sub protocols or different uses
for this generic protocol. The PFP Type specifies which sub
protocol it is used for.
[U]nsupported-No-Forwarding bit: When the No-Forward bit defined
above is not set, whether to forward the message depends on
whether the PFP type is supported and the setting of the
Unsupported-No-Forwarding bit. Some sub protocols may require
that each router do some processing of the contents and not simply
forward the message. When Unsupported-No-Forwarding bit is set, a
router MUST NOT forward the message when the PFP Type is
unsupported. When it is not set, a router MUST forward the
message when possible. If the PFP Type is supported, then the
specification of that type will specify how to handle the message,
including whether the message should be forwarded.
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. Note that the Type space is shared between all PFP types. Value.
Not all types make sense for all PFP types though.
Length 1..n: The length of the the value field. Length 1..n: The length of the the value field.
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. Processing PFP messages 3.2. Processing PFM messages
A router that receives an PFP 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 PFP type if supported. If the type is unsupported it may still the processing rules of the included TLVs.
be forwarded if neither the No-Forward bit nor the Unsupported-No-
Forwarding bit are set.
3.2.1. Initial checks 3.2.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 neighbor requirements. The message MUST be from a directly connected neighbor
for which we have active Hello state, and it MUST have been sent to for which we have active Hello state, and it MUST have been sent to
the ALL-PIM-ROUTERS group. Also, the interface MUST NOT be an the ALL-PIM-ROUTERS group. Also, the interface MUST NOT be an
administrative boundary for the message's PFP type. If No-Forward is administrative boundary for PFM. If No-Forward is not set, it MUST
not set, it MUST have been sent by the RPF neighbor towards the have been sent by the RPF neighbor for the originator address. If
router that originated the message. If No-Forward is set, we MUST No-Forward is set, we MUST have restarted within 60 seconds. In
have restarted within 60 seconds. In pseudo-code the algorithm is as pseudo-code the algorithm is as follows:
follows:
if ((DirectlyConnected(PFP.src_ip_address) == FALSE) OR if ((DirectlyConnected(PFM.src_ip_address) == FALSE) OR
(we have no Hello state for PFP.src_ip_address) OR (we have no Hello state for PFM.src_ip_address) OR
(PFP.dst_ip_address != ALL-PIM-ROUTERS) OR (PFM.dst_ip_address != ALL-PIM-ROUTERS) OR
(Incoming interface is admin boundary for PFP.type)) { (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.
}
} else if (more than 60 seconds elapsed since startup)) {
drop the message silently, optionally log error. drop the message silently, optionally log error.
} }
if (PFP.no_forward_bit == 0) {
if (PFP.src_ip_address !=
RPF_neighbor(PFP.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.
}
3.2.2. Processing messages of supported PFP type 3.2.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 we continue as follows. If performed. If it passes the checks, we then for each included TLV
the PFP type is supported by the implementation, the processing and perform processing according to the specification for that TLV.
potential forwarding is done according to the specification for that
PFP type. If the PFP type specification does not specify any
particular forwarding rules, the message is forwarded out of all
interfaces with PIM neighbors (including the interface it was
received on).
3.2.3. Processing messages of unsupported PFP type
When the message is received, the initial checks above must be After processing, we forward the message. Unless otherwise specified
performed. If it passes the checks, then we continue as follows. If by the type specification, the TLVs in the forwarded message are
the PFP type is unsupported, the message MUST be dropped if the identical to the TLVs in the received message. However, if the most
Unsupported-No-Forwarding bit is set. If the bit is not set, the significant bit in the type field is set (the type value is larger
message is forwarded out of all interfaces with PIM neighbors than 32767) and we do not support the type, then that particular type
(including the interface it was received on). should be omitted from the forwarded messages. The message is
forwarded out of all interfaces with PIM neighbors (including the
interface it was received on).
4. Distributing Source to Group Mappings 4. Distributing Source to Group Mappings
We want to provide information about active multicast sources The generic flooding mechanism (PFM) defined in the previous section
throughout a PIM domain by making use of the generic flooding can be used for distributing source to group mappings about active
mechanism defined in the previous section. We request PFP Type 0 to multicast sources throughout a PIM domain. A Group Source Holtime
be assigned for this purpose. We call a message with PFP Type 0 an (GSH) TLV is defined for this purpose.
SG Message. We also define a PFP TLV which we request to be type 0.
How this TLV is used with PFP Type 0 is defined in the next section.
Other PFP Types may specify the use of this TLV for other purposes.
For PFP Type 0 the U-bit MUST NOT be set. This means that routers
not supporting PFP Type 0 would still forward the message.
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 | | Type = 0 | 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) |
skipping to change at page 8, line 44 skipping to change at page 7, line 41
Src Count: How many unicast encoded sources address encodings Src Count: How many unicast encoded sources address encodings
follow. follow.
Src Holdtime: The Holdtime (in seconds) for the corresponding Src Holdtime: The Holdtime (in seconds) for the corresponding
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 SG messages 4.2. Originating PFM messages
An SG Message, that is a PFP message of Type 0, MAY contain one or A PFM message MAY contain one or more Group Source Holdtime (GSH)
more Group Source Holdtime TLVs. This is used to flood information TLVs. This is used to flood information about active multicast
about active multicast sources. Each FHR that is directly connected sources. Each FHR that is directly connected to an active multicast
to an active multicast source originates SG BSR messages. How a source originates PFM messages containing GSH TLVs. How a multicast
multicast router discovers the source of the multicast packet and router discovers the source of the multicast packet and when it
when it considers itself the FHR follows the same procedures as the considers itself the FHR follows the same procedures as the
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 SG message. Note, only the SG mapping is distributed included in an GSH TLV in a PFM message. Note, only the SG mapping
in the message, not the entire packet as would have been done with a is distributed in the message, not the entire packet as would have
PIM register. The router originating the SG messages includes one of been done with a PIM register. The router originating the PFM
its own addresses in the originator field. Note that this address messages includes one of its own addresses in the originator field.
SHOULD be routeable due to RPF checking. The SG messages are Note that this address SHOULD be routeable due to RPF checking. The
periodically sent for as long as the multicast source is active, PFM messages containing the GSH TLV are periodically sent for as long
similar to how PIM registers are periodically sent. The default as the multicast source is active, similar to how PIM registers are
announcement period is 60 seconds, which means that as long as the periodically sent. The default announcement period is 60 seconds,
source is active, it is included in an SG message originated every 60 which means that as long as the source is active, it is included in a
seconds. The holdtime for the source is by default 210 seconds. PFM message originated every 60 seconds. The holdtime for the source
Other values MAY be configured, but the holdtime MUST be either zero, is by default 210 seconds. Other values MAY be configured, but the
or larger than the announcement period. It is RECOMMENDED to be 3.5 holdtime MUST be either zero, or larger than the announcement period.
times the announcement period. A source MAY be announced with a It is RECOMMENDED to be 3.5 times the announcement period. A source
holdtime of zero to indicate that the source is no longer active. MAY be announced with a holdtime of zero to indicate that the source
is no longer active.
4.3. Processing SG messages If an implementation supports originating GSH TLVs with different
holdtimes for different sources, it can if needed send multiple TLVs
with the same group address. Due to the format, all the sources in
the same TLV have the same holdtime.
A router that receives an SG message SHOULD parse the message and 4.3. Processing GSH TLVs
store the SG mappings with a holdtimer started with the advertised
holdtime for that group. For each group that has directly connected A router that receives a PFM message containing GSH TLVs SHOULD parse
receivers, this router SHOULD send PIM (S,G) joins for all the SG the message and store each of the GSH TLVs as SG mappings with a
mappings advertised in the message for the group. The SG mappings holdtimer started with the advertised holdtime. For each group that
are kept alive for as long as the holdtimer for the source is has directly connected receivers, this router SHOULD send PIM (S,G)
running. Once the holdtimer expires a PIM router SHOULD send a PIM joins for all the SG mappings advertised in the message for the
(S,G) prune to remove itself from the tree. Note that a holdtime of group. The SG mappings are kept alive for as long as the holdtimer
zero has a special meaning. It is to be treated as if the source for the source is running. Once the holdtimer expires a PIM router
just expired, causing a prune to be sent and state to be removed. MAY send a PIM (S,G) prune to remove itself from the tree. However,
Source information MUST NOT be removed due to it being omitted in a when this happens, there should be no more packets sent by the
message. For instance, if there are a large number of sources for a source, so it may be desirable to allow the state to time out rather
group, there may be multiple SG messages for the same group, each than sending a prune.
message containing a different list of sources.
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.
Source information MUST NOT be removed due to the source being
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
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.
skipping to change at page 11, line 14 skipping to change at page 10, line 22
Mappings and join the source tree. Each partition works Mappings and join the source tree. Each partition works
independently of the other partition(s) and will continue to have independently of the other partition(s) and will continue to have
access to sources within that partition. As soon as the network access to sources within that partition. As soon as the network
heals, the SG Mappings are re-flooded into the other partition(s) and heals, the SG Mappings are re-flooded into the other partition(s) and
other receivers can join to the newly learned sources. other receivers can join to the newly learned sources.
5. Security Considerations 5. Security Considerations
The security considerations are mainly similar to what is documented The security considerations are mainly similar to what is documented
in [RFC5059]. It is a concern that rogue devices can inject packets in [RFC5059]. It is a concern that rogue devices can inject packets
that are flooded throughout a domain. PFP packets must only be that are flooded throughout a domain. PFM packets must only be
accepted from a PIM neighbor. Deployments may use mechanisms for accepted from a PIM neighbor. Deployments may use mechanisms for
authenticating PIM neighbors. For PFP-SA it is an issue that authenticating PIM neighbors. For PFM-SA it is an issue that
injected packets from a rogue device could send SG mappings for a injected packets from a rogue device could send SG mappings for a
large number of source addresses, causing routers to use memory large number of source addresses, causing routers to use memory
storing these mappings, and also if they have interest in the groups, storing these mappings, and also if they have interest in the groups,
build Shortest Path Trees for sources that are not actually active. build Shortest Path Trees for sources that are not actually active.
6. IANA considerations 6. IANA considerations
This document requires the assignment of a new PIM Protocol type for This document requires the assignment of a new PIM message type for
the PIM Flooding Protocol (PFP). IANA is also requested to create a the PIM Flooding Mechanism (PFM). IANA is also requested to create a
registry for PFP Types with type 0 assigned to "Source-Group registry for PFM TLVs, with type 0 assigned to the "Source Group
Message". IANA is also requested to create a registry for PFP TLVs, Holdtime" TLV. Values in the range 1-65535 are "Unassigned".
with type 0 assigned to the "Source Group Holdtime" TLV. Assignments Assignments for the registry are to be made according to the policy
for both registries are to be made according to the policy "IETF "IETF Review" as defined in [RFC5226].
Review" as defined in [RFC5226].
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 for his comments on the draft. initial idea, and Yiqun Cai and Dino Farinacci for their 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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 40 change blocks. 
173 lines changed or deleted 148 lines changed or added

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