draft-ietf-pim-source-discovery-bsr-08.txt   draft-ietf-pim-source-discovery-bsr-09.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: July 20, 2018 M. Brig Expires: July 29, 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)
January 16, 2018 January 25, 2018
PIM Flooding Mechanism and Source Discovery PIM Flooding Mechanism and Source Discovery
draft-ietf-pim-source-discovery-bsr-08 draft-ietf-pim-source-discovery-bsr-09
Abstract Abstract
PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared
trees to forward multicast packets from new sources. Once last hop trees to forward multicast packets from new sources. Once last hop
routers receive packets from a new source, they may join the Shortest routers receive packets from a new source, they may join the Shortest
Path Tree for the source for optimal forwarding. This draft defines Path Tree for the source for optimal forwarding. This draft defines
a new mechanism that provides a way to support PIM-SM without the a new mechanism that provides a way to support PIM-SM without 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
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 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 July 20, 2018. This Internet-Draft will expire on July 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . 9
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 . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 12 4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 12
4.4. The First Packets and Bursty Sources . . . . . . . . . . 12 4.4. The First Packets and Bursty Sources . . . . . . . . . . 13
4.5. Resiliency to Network Partitioning . . . . . . . . . . . 13 4.5. Resiliency to Network Partitioning . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared
trees to forward multicast packets to Last Hop Routers (LHR). After trees to forward multicast packets to Last Hop Routers (LHR). After
skipping to change at page 5, line 17 skipping to change at page 5, line 17
network 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; the messages are link-local and each router will process and
mechanism;, there can be multiple originators. This mechanism is resend the messages. Note that there is no equivalent to the BSR
named the PIM Flooding Mechanism (PFM). election mechanism; there can be multiple originators. This
mechanism is 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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
be sent when there is a local state change, causing information to be be sent when there is a local state change, causing information to be
distributed with PFM to change. Also, some information may need to distributed with PFM to change. Also, some information may need to
be sent periodically. These messages are called triggered and be sent periodically. These messages are called triggered and
periodic messages, respectively. Each TLV definition will need to periodic messages, respectively. Each TLV definition will need to
define when a triggered PFM message needs to be originated, and also define when a triggered PFM message needs to be originated, and also
whether to send periodic messages, and how frequent. whether to send periodic messages, and how frequent.
A router MUST NOT originate more than N messages per minute. This
document does not mandate how this should be implemented, but some
possible ways could be having a minimal time between each message,
counting the number of messages originated and resetting the count
every minute, or using a leaky bucket algorithm. One benefit of
using a leaky bucket algorithm is that it can handle bursts better.
The default value of N is 6. The value MUST be configurable.
Depending on the network one may want to use a low value allowing new
information to be propagated, but with a large number of routers and
many updates, the total number of messages might become too large and
require too much processing.
There MUST be a minimum of M milliseconds between each originated
message. The default value of M is 1000 (1 second). The value MUST
be configurable.
Unless otherwise specified by the TLV definitions, there is no Unless otherwise specified by the TLV definitions, there is no
relationship between different TLVs, and an implementation can choose relationship between different TLVs, and an implementation can choose
whether to combine TLVs in one message or across separate messages. whether to combine TLVs in one message or across separate messages.
It is RECOMMENDED to combine multiple TLVs in one message, to reduce It is RECOMMENDED to combine multiple TLVs in one message, to reduce
the number of messages, but it is also RECOMMENDED that the message the number of messages, but it is also RECOMMENDED that the message
is small enough to avoid fragmentation at the IP layer. When a is small enough to avoid fragmentation at the IP layer. When a
triggered PFM message needs to be sent due to a state change, a triggered PFM message needs to be sent due to a state change, a
router MAY send a message containing only the information that router MAY send a message containing only the information that
changed. If there are many changes occuring at about the same time, changed. If there are many changes occuring at about the same time,
it might be possible to combine multiple changes in one message. In it might be possible to combine multiple changes in one message. In
skipping to change at page 11, line 29 skipping to change at page 12, line 5
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
source originates PFM messages containing GSH TLVs. How a multicast source originates PFM messages containing GSH TLVs. How a multicast
router discovers the source of the multicast packet and when it router discovers the source of the multicast packet and 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 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 MUST be either zero, every 60 seconds. The holdtime for the source MUST be either zero,
or larger than the announcement period. It is RECOMMENDED to be 3.5 or larger than the announcement period. It is RECOMMENDED to be 3.5
times the announcement period. The default holdtime is 210 seconds, times the announcement period. The default holdtime is 210 seconds,
skipping to change at page 11, line 52 skipping to change at page 12, line 28
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. Note that when a
new source is detected, one should trigger sending of a PFM message
as soon as possible, while if a source becomes inactive, there is no
reason to trigger a message. There is no urgency in removing state
for inactive sources.
When a new PIM neighbor is detected, or an existing neighbor changes When a new PIM neighbor is detected, or an existing neighbor changes
Generation Identifier, an implementation MAY send a triggered PFM Generation Identifier, an implementation MAY send a triggered PFM
message containing GSH TLVs for any Source Group mappings it has message containing GSH TLVs for any Source Group mappings it has
learned by receiving PFM GSH TLVs as well as any active directly learned by receiving PFM GSH TLVs as well as any active directly
connected sources. See 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
 End of changes. 12 change blocks. 
14 lines changed or deleted 35 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/