draft-ietf-pim-source-discovery-bsr-03.txt   draft-ietf-pim-source-discovery-bsr-04.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: January 2, 2016 M. Brig Expires: September 18, 2016 M. Brig
Aegis BMD Program Office Aegis BMD Program Office
A. Jonasson A. Jonasson
Swedish Defence Material Administration (FMV) Swedish Defence Material Administration (FMV)
July 1, 2015 March 17, 2016
PIM flooding mechanism and source discovery PIM flooding mechanism and source discovery
draft-ietf-pim-source-discovery-bsr-03 draft-ietf-pim-source-discovery-bsr-04
Abstract Abstract
PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward
forward multicast packets to Last Hop Routers (LHR). After the first multicast packets from new sources. Once last hop routers receive
packet is received by the LHR, the source of the multicast stream is packets from a new source, they may join the Shortest Path Tree for
learned and the Shortest Path Tree (SPT) can be joined. This draft the source for optimal forwarding. This draft defines a new protcol
proposes a solution 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
flooding mechanism. This mechanism is defined in this document, and flooding mechanism. This allows last hop routers to learn about new
is modeled after the PIM Bootstrap Router protocol. By removing the sources without receiving initial data packets.
need for RPs and shared trees, the PIM-SM procedures are simplified,
improving router operations, management and making the protocol more
robust.
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 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 January 2, 2016. This Internet-Draft will expire on September 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
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
skipping to change at page 2, line 30 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 . . . . . . . . . . . . . . . . . . . . . . . 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. PFP message format . . . . . . . . . . . . . . . . . . . 4
3.2. Processing PFP messages . . . . . . . . . . . . . . . . . 6 3.2. Processing PFP messages . . . . . . . . . . . . . . . . . 6
3.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 6 3.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 6
3.2.2. Processing messages with known PFP type . . . . . . . 6 3.2.2. Processing messages of supported PFP type . . . . . . 7
3.2.3. Processing messages with unknown PFP type . . . . . . 6 3.2.3. Processing messages of unsupported PFP type . . . . . 7
4. Distributing Source to Group Mappings . . . . . . . . . . . . 7 4. Distributing Source to Group Mappings . . . . . . . . . . . . 7
4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 7 4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 8
4.2. Originating SG messages . . . . . . . . . . . . . . . . . 8 4.2. Originating SG messages . . . . . . . . . . . . . . . . . 8
4.3. Processing SG messages . . . . . . . . . . . . . . . . . 8 4.3. Processing SG messages . . . . . . . . . . . . . . . . . 9
4.4. The first packets and bursty sources . . . . . . . . . . 9 4.4. The first packets and bursty sources . . . . . . . . . . 9
4.5. Resiliency to network partitioning . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 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 the 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
proposes a solution to support PIM Sparse Mode (SM) without the need defines a new protocol that provides a way to support PIM Sparse Mode
for PIM registers, RPs or shared trees. Multicast source information (SM) without the need for PIM registers, RPs or shared trees.
is flooded throughout the multicast domain using a new generic PIM Multicast source information is flooded throughout the multicast
flooding mechanism. This mechanism is defined in this document, and domain using a new generic PIM flooding mechanism. This mechanism is
is modeled after the Bootstrap Router protocol [RFC5059]. By defined in this document, and is modeled after the Bootstrap Router
removing the need for RPs and shared trees, the PIM-SM procedures are protocol [RFC5059]. By removing the need for RPs and shared trees,
simplified, improving router operations, management and making the the PIM-SM procedures are simplified, improving router operations,
protocol more robust. management and making the protocol more robust. Also the data
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].
1.2. Terminology 1.2. Terminology
RP: Rendezvous Point. RP: Rendezvous Point.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
| Type n | Length n | | Type n | Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value n | | Value n |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version: Reserved, Checksum Described in [RFC4601]. 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 PFP 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 PFP message is
not to be forwarded. not to be forwarded. This is irrespective of the value of the
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 this router, but message. This can be any address assigned to the originating
MUST be routable in the domain to allow successful forwarding router, but MUST be routable in the domain to allow successful
(just like BSR address). The format for this address is given in forwarding (just like BSR address). The format for this address
the Encoded-Unicast address in [RFC4601]. is given in the Encoded-Unicast address in [RFC7761].
PFP Type: There may be different sub protocols or different uses PFP Type: There may be different sub protocols or different uses
for this generic protocol. The PFP Type specifies which sub for this generic protocol. The PFP Type specifies which sub
protocol it is used for. protocol it is used for.
[U]nknown-No-Forwarding bit: Some sub protocols may require that [U]nsupported-No-Forwarding bit: When the No-Forward bit defined
each router do some processing of the contents and not simply above is not set, whether to forward the message depends on
forwarding. This bit controls how a router should treat an whether the PFP type is supported and the setting of the
unknown PFP Type. When set, a router MUST NOT forward the message Unsupported-No-Forwarding bit. Some sub protocols may require
when the PFP Type is unknown. When clear, a router MUST forward that each router do some processing of the contents and not simply
the message when possible. If the PFP Type is known, then the 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, specification of that type will specify how to handle the message,
including whether it should be forwarded. 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. Note that the Type space is shared between all PFP types.
Not all types make sense for all PFP types though. 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 PFP messages
A router that receives an PFP message must perform the initial checks A router that receives an PFP message MUST perform the initial checks
specified here. If it passes, the contents is processed according to specified here. If the checks fail, the message MUST be dropped. An
the PFP type if known. If the type is unknown it may still be error MAY be logged, but otherwise the message MUST be dropped
forwarded. silently. If the checks pass, the contents is processed according to
the PFP type if supported. If the type is unsupported it may still
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
The initial checks performed are largely similar to what is done for In order to do further processing, a message MUST meet the following
BSR messages. 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. It MUST have been sent to the for which we have active Hello state, and it MUST have been sent to
ALL-PIM-ROUTERS group, and unless No-Forward is set, it MUST have the ALL-PIM-ROUTERS group. Also, the interface MUST NOT be an
been sent by the RPF neighbor towards the router that originated the administrative boundary for the message's PFP type. If No-Forward is
message; or, if it is a No-Forward BSM, we must have restarted within not set, it MUST have been sent by the RPF neighbor towards the
60 seconds. router that originated the message. If No-Forward is set, we MUST
have restarted within 60 seconds. In pseudo-code the algorithm is as
follows:
3.2.2. Processing messages with known PFP type if ((DirectlyConnected(PFP.src_ip_address) == FALSE) OR
(we have no Hello state for PFP.src_ip_address) OR
(PFP.dst_ip_address != ALL-PIM-ROUTERS) OR
(Incoming interface is admin boundary for PFP.type)) {
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.
}
If the PFP type is known, as in supported by the implementation, the 3.2.2. Processing messages of supported PFP type
processing and 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
is received on).
3.2.3. Processing messages with unknown PFP type When the message is received, the initial checks above must be
performed. If it passes the checks, then we continue as follows. If
the PFP type is supported by the implementation, the processing and
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).
If the PFP type is unknown, the message MUST be dropped if the 3.2.3. Processing messages of unsupported PFP type
Unknown-No-Forwarding bit is set. If the bit is not set, the message
is forwarded out of all interfaces with PIM neighbors (including the When the message is received, the initial checks above must be
interface it is received on). performed. If it passes the checks, then we continue as follows. If
the PFP type is unsupported, the message MUST be dropped if the
Unsupported-No-Forwarding bit is set. If the bit is not set, 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 We want to provide information about active multicast sources
throughout a PIM domain by making use of the generic flooding throughout a PIM domain by making use of the generic flooding
mechanism defined in the previous section. We request PFP Type 0 to mechanism defined in the previous section. We request PFP Type 0 to
be assigned for this purpose. We call a message with PFP Type 0 an be assigned for this purpose. We call a message with PFP Type 0 an
SG Message. We also define a PFP TLV which we request to be type 0. 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. 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. Other PFP Types may specify the use of this TLV for other purposes.
skipping to change at page 7, line 44 skipping to change at page 8, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) | | Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: This TLV has type 0. Type: This TLV has type 0.
Length: The length of the value. Length: The length of the value.
Group Address: The group we are announcing sources for. The format Group Address: The group we are announcing sources for. The format
for this address is given in the Encoded-Group format in for this address is given in the Encoded-Group format in
[RFC4601]. [RFC7761].
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 [RFC4601]. in [RFC7761].
4.2. Originating SG messages 4.2. Originating SG messages
An SG Mesage, that is a PFP message of Type 0, may contain one or An SG Message, that is a PFP message of Type 0, MAY contain one or
more Group Source Holdtime TLVs. This is used to flood information more Group Source Holdtime TLVs. This is used to flood information
about active multicast sources. Each FHR that is directly connected about active multicast sources. Each FHR that is directly connected
to an active multicast source originates SG BSR messages. How a to an active multicast source originates SG BSR messages. How a
multicast router discovers the source of the multicast packet and multicast router discovers the source of the multicast packet and
when it considers itself the FHR follows the same procedures as the when it considers itself the FHR follows the same procedures as the
registering process described in [RFC4601]. After it is decided that registering process described in [RFC7761]. When a FHR has decided
a register needs to be sent, the SG is not registered via the PIM SM that a register needs to be sent per [RFC7761], the SG is not
register procedures, but the SG mapping is included in an SG message. registered via the PIM SM register procedures, but the SG mapping is
Note, only the SG mapping is distributed in the message, not the included in an SG message. Note, only the SG mapping is distributed
entire packet as would have been done with a PIM register. The in the message, not the entire packet as would have been done with a
router originating the SG messages includes one of its own addresses PIM register. The router originating the SG messages includes one of
in the originator field. Note that this address must be routeable its own addresses in the originator field. Note that this address
due to RPF checking. The SG messages are periodically sent for as SHOULD be routeable due to RPF checking. The SG messages are
long as the multicast source is active, similar to how PIM registers periodically sent for as long as the multicast source is active,
are periodically sent. The default announcement period is 60 similar to how PIM registers are periodically sent. The default
seconds, which means that as long as the source is active, it is announcement period is 60 seconds, which means that as long as the
included in an SG message originated every 60 seconds. The holdtime source is active, it is included in an SG message originated every 60
for the source is by default 210 seconds. Other values can be seconds. The holdtime for the source is by default 210 seconds.
configured, but the holdtime must be larger than the announcement Other values MAY be configured, but the holdtime MUST be either zero,
period. It is RECOMMENDED to be 3.5 times the announcement period. or larger than the announcement period. It is RECOMMENDED to be 3.5
Note that as a special case a source MAY be announced with a holdtime times the announcement period. A source MAY be announced with a
of 0 to indicate that the source is no longer active. holdtime of zero to indicate that the source is no longer active.
4.3. Processing SG messages 4.3. Processing SG messages
A router that receives an SG message should parse the message and A router that receives an SG message SHOULD parse the message and
store the SG mappings with a holdtimer started with the advertised store the SG mappings with a holdtimer started with the advertised
holdtime for that group. If there are directly connected receivers holdtime for that group. For each group that has directly connected
for that group this router should send PIM (S,G) joins for all the SG receivers, this router SHOULD send PIM (S,G) joins for all the SG
mappings advertised in the message. The SG mappings are kept alive mappings advertised in the message for the group. The SG mappings
for as long as the holdtimer for the source is running. Once the are kept alive for as long as the holdtimer for the source is
holdtimer expires a PIM router SHOULD send a PIM (S,G) prune to running. Once the holdtimer expires a PIM router SHOULD send a PIM
remove itself from the tree. Note that a holdtime of 0 has a special (S,G) prune to remove itself from the tree. Note that a holdtime of
meaning. It is to be treated as if the source just expired, causing zero has a special meaning. It is to be treated as if the source
a prune to be sent and state to be removed. Source information MUST just expired, causing a prune to be sent and state to be removed.
not be removed due to it being omitted in a message. For instance, Source information MUST NOT be removed due to it being omitted in a
if there are a large number of sources for a group, there may be message. For instance, if there are a large number of sources for a
multiple SG messages for the same group, each message containing a group, there may be multiple SG messages for the same group, each
different list of sources. message containing a different list of sources.
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 native SPT tree from the RP to the to the RP in the absence of a Shortest Path Tree (SPT) from the RP to
source. The register packets received on the RP are decapsulated and the source. The register packets received on the RP are decapsulated
forwarded down the shared tree to the LHRs. As soon as an SPT tree and forwarded down the shared tree to the LHRs. As soon as an SPT is
is built, multicast packets would flow natively over the SPT to the built, multicast packets would flow natively over the SPT to the RP
RP or LHR and the register process would stop. The PIM register or LHR and the register process would stop. The PIM register process
process ensures packet delivery until an SPT tree is in place ensures packet delivery until an SPT is in place reaching the FHR.
reaching the FHR. If the packets were not unicast encapsulated to If the packets were not unicast encapsulated to the RP they would be
the RP they would be dropped by the FHR until the SPT is setup. This dropped by the FHR until the SPT is setup. This functionality is
functionality is important for applications where the initial important for applications where the initial packet(s) must be
packet(s) must be received for the application to work correctly. received for the application to work correctly. Another reason would
Another reason would be for bursty sources. If the application sends be for bursty sources. If the application sends out a multicast
out a multicast packet every 4 minutes (or longer), the SPT is torn packet every 4 minutes (or longer), the SPT is torn down (typically
down (typically after 3:30 minutes of inactivity) before the next after 3:30 minutes of inactivity) before the next packet is forwarded
packet is forwarded down the tree. This will cause no multicast down the tree. This will cause no multicast packet to ever be
packet to ever be forwarded. A well behaved application should forwarded. A well behaved application should be able to deal with
really be able to deal with packet loss since IP is a best effort packet loss since IP is a best effort based packet delivery system.
based packet delivery system. But in reality this is not always the But in reality this is not always the case.
case.
With the procedures proposed in this draft the packet(s) received by With the procedures defined in this document the packet(s) received
the FHR will be dropped until the LHR has learned about the source by the FHR will be dropped until the LHR has learned about the source
and the SPT tree is built. That means for bursty sources or and the SPT is built. That means for bursty sources or applications
applications sensitive for the delivery of the first packet this sensitive for the delivery of the first packet this solution would
proposal would not be very applicable. This proposal is mostly not be very applicable. This solution is mostly useful for
useful for applications that don't have strong dependency on the applications that don't have strong dependency on the initial
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) we recommend using PIM Bidir [RFC5015] or SSM the initial packet(s) we recommend using PIM Bidir [RFC5015] or SSM
[RFC4607]. The protocol operations are much simpler compared to PIM [RFC4607]. The protocol operations are much simpler compared to PIM
SM, it will cause less churn in the network and both guarantee best SM, it will cause less churn in the network and both guarantee best
effort delivery for the initial packet(s). effort delivery for the initial packet(s).
Another solution to address the problems described above is Another solution to address the problems described above is
documented in [I-D.ietf-magma-msnip]. This proposal allows for a documented in [I-D.ietf-magma-msnip]. This proposal allows for a
host to tell the FHR its willingness to act as Source for a certain host to tell the FHR its willingness to act as Source for a certain
Group before sending the data packets. LHRs have time to join the Group before sending the data packets. LHRs have time to join the
SPT tree before the host starts sending which would avoid packet SPT before the host starts sending which would avoid packet loss.
loss. The SG mappings announced by [I-D.ietf-magma-msnip] can be The SG mappings announced by [I-D.ietf-magma-msnip] can be advertised
advertised directly in SG messages, allowing a very nice integration directly in SG messages, allowing a nice integration of both
of both proposals. The life time of the SPT is not driven by the proposals. The life time of the SPT is not driven by the liveliness
liveliness of Multicast data packets (which is the case with PIM SM), of Multicast data packets (which is the case with PIM SM), but by the
but by the announcements driven via [I-D.ietf-magma-msnip]. This announcements driven via [I-D.ietf-magma-msnip]. This will also
will also prevent packet loss due to bursty sources. prevent packet loss due to bursty sources.
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.
skipping to change at page 10, line 30 skipping to change at page 11, line 13
active, the receivers in that partitioned will receive the SG active, the receivers in that partitioned will receive the SG
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 may be a concern that rogue devices can inject in [RFC5059]. It is a concern that rogue devices can inject packets
packets that are flooded throughout a domain. PFP packets SHOULD that are flooded throughout a domain. PFP packets must only be
only be accepted from a PIM neighbor. Deployments may use mechanisms accepted from a PIM neighbor. Deployments may use mechanisms for
for authenticating PIM neighbors. authenticating PIM neighbors. For PFP-SA it is an issue that
injected packets from a rogue device could send SG mappings for a
large number of source addresses, causing routers to use memory
storing these mappings, and also if they have interest in the groups,
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 Protocol type for
the PIM Flooding Protocol (PFP). IANA is also requested to create a the PIM Flooding Protocol (PFP). IANA is also requested to create a
registry for PFP Types with type 0 allocated to "Source-Group registry for PFP Types with type 0 assigned to "Source-Group
Message". IANA is also requested to create a registry for PFP TLVs, Message". IANA is also requested to create a registry for PFP TLVs,
with type 0 allocated to the "Source Group Holdtime" TLV. The with type 0 assigned to the "Source Group Holdtime" TLV. Assignments
allocation procedures are yet to be determined. for both registries are to be made according to the policy "IETF
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 for his 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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, <http://www.rfc-editor.org/info/rfc2119>.
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[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, January 2008. Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January
2008, <http://www.rfc-editor.org/info/rfc5059>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>.
8.2. Informative References 8.2. Informative References
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<http://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, October 2007. PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[I-D.ietf-magma-msnip] [I-D.ietf-magma-msnip]
Fenner, B., Haberman, B., Holbrook, H., Kouvelas, I., and Fenner, B., Haberman, B., Holbrook, H., Kouvelas, I., and
S. Venaas, "Multicast Source Notification of Interest S. Venaas, "Multicast Source Notification of Interest
Protocol (MSNIP)", draft-ietf-magma-msnip-06 (work in Protocol (MSNIP)", draft-ietf-magma-msnip-06 (work in
progress), March 2011. progress), March 2011.
Authors' Addresses Authors' Addresses
IJsbrand Wijnands IJsbrand Wijnands
 End of changes. 41 change blocks. 
149 lines changed or deleted 191 lines changed or added

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