draft-ietf-pim-source-discovery-bsr-02.txt   draft-ietf-pim-source-discovery-bsr-03.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
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: January 2, 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 July 1, 2015
PIM flooding mechanism and source discovery PIM flooding mechanism and source discovery
draft-ietf-pim-source-discovery-bsr-02 draft-ietf-pim-source-discovery-bsr-03
Abstract Abstract
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 the 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 proposes a solution 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 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . 3
2. A generic PIM flooding mechanism . . . . . . . . . . . . . . 3 2. Testing and deployment experiences . . . . . . . . . . . . . 3
2.1. PFP message format . . . . . . . . . . . . . . . . . . . 4 3. A generic PIM flooding mechanism . . . . . . . . . . . . . . 4
2.2. Processing PFP messages . . . . . . . . . . . . . . . . . 5 3.1. PFP message format . . . . . . . . . . . . . . . . . . . 4
2.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 5 3.2. Processing PFP messages . . . . . . . . . . . . . . . . . 6
2.2.2. Processing messages with known PFP type . . . . . . . 5 3.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 6
2.2.3. Processing messages with unknown PFP type . . . . . . 6 3.2.2. Processing messages with known PFP type . . . . . . . 6
3. Distributing Source to Group Mappings . . . . . . . . . . . . 6 3.2.3. Processing messages with unknown PFP type . . . . . . 6
3.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 6 4. Distributing Source to Group Mappings . . . . . . . . . . . . 7
3.2. Originating SG messages . . . . . . . . . . . . . . . . . 7 4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 7
3.3. Processing SG messages . . . . . . . . . . . . . . . . . 7 4.2. Originating SG messages . . . . . . . . . . . . . . . . . 8
3.4. The first packets and bursty sources . . . . . . . . . . 8 4.3. Processing SG messages . . . . . . . . . . . . . . . . . 8
3.5. Resiliency to network partitioning . . . . . . . . . . . 9 4.4. The first packets and bursty sources . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4.5. Resiliency to network partitioning . . . . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 the 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 proposes a solution 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 3, line 35 skipping to change at page 3, line 36
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. SG Mapping: Multicast source to group mapping.
SG Message: A PIM message containing SG Mappings. SG Message: A PIM message containing SG Mappings.
2. A generic PIM flooding mechanism 2. Testing and deployment experiences
A prototype of this specification has been implemented and there has
been some limited testing in the field. The prototype was tested in
a network with low bandwidth radio links. In this network with
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
with new multicast sources starving low bandwidth links even when
there are no receivers, in some cases such that there were no
bandwidth left for prune message. For the tests, all routers were
configured to send PFP-SA for directly connected source and to cache
received announcements. Applications such as SIP with multicast
subscriber discovery, multicast voice conferencing, position tracking
and NTP were successfully tested. The tests went quite well.
Packets were rerouted as needed and there were no unnecessary
forwarding of packets. Ease of configuration was seen as a plus.
3. A generic PIM flooding mechanism
The Bootstrap Router protocol (BSR) [RFC5059] is a commonly used The Bootstrap Router protocol (BSR) [RFC5059] is a commonly used
protocol for distributing dynamic Group to RP mappings in PIM. It is protocol for distributing dynamic Group to RP mappings in PIM. It is
responsible for flooding information about such mappings throughout a responsible for flooding information about such mappings throughout a
PIM domain, so that all routers in the domain can have the same PIM domain, so that all routers in the domain can have the same
information. BSR as defined, is only able to distribute Group to RP information. BSR as defined, is only able to distribute Group to RP
mappings. We are defining a more generic mechanism that can flood mappings. We are defining a more generic mechanism that can flood
any kind of information throughout a PIM domain. It is not 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
skipping to change at page 4, line 13 skipping to change at page 4, line 31
single router to support it. The protocol includes an originator single router to support it. The protocol includes an originator
address which is used for RPF checking to restrict the flooding, just address which is used for RPF checking to restrict the flooding, just
like BSR. Just like BSR it is also sent hop by hop. Note that there like BSR. Just like BSR it is also sent hop by hop. Note that there
is no built in election mechanism as in BSR, so there can be multiple is no built in election mechanism as in BSR, so there can be multiple
originators. It is still possible to add such an election mechanism originators. It is still possible to add such an election mechanism
on a type by type bases if this protocol is used in scenarios where on a type by type bases if this protocol is used in scenarios where
this is desirable. We include a type field, which can allow this is desirable. We include a type field, which can allow
boundaries to be defined, and election to take place, independently boundaries to be defined, and election to take place, independently
per type. We call this protocol the PIM Flooding Protocol (PFP). per type. We call this protocol the PIM Flooding Protocol (PFP).
2.1. PFP message format 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| | PFP Type | Reserved |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 1 | Length 1 | | Type 1 | Length 1 |
skipping to change at page 5, line 28 skipping to change at page 6, line 17
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.
2.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 it passes, the contents is processed according to
the PFP type if known. If the type is unknown it may still be the PFP type if known. If the type is unknown it may still be
forwarded. forwarded.
2.2.1. Initial checks 3.2.1. Initial checks
The initial checks performed are largely similar to what is done for The initial checks performed are largely similar to what is done for
BSR messages. The message MUST be from a directly connected neighbor BSR messages. 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. It MUST have been sent to the
ALL-PIM-ROUTERS group, and unless No-Forward is set, it MUST have ALL-PIM-ROUTERS group, and unless No-Forward is set, it MUST have
been sent by the RPF neighbor towards the router that originated the been sent by the RPF neighbor towards the router that originated the
message; or, if it is a No-Forward BSM, we must have restarted within message; or, if it is a No-Forward BSM, we must have restarted within
60 seconds. 60 seconds.
2.2.2. Processing messages with known PFP type 3.2.2. Processing messages with known PFP type
If the PFP type is known, as in supported by the implementation, the If the PFP type is known, as in supported by the implementation, the
processing and potential forwarding is done according to the processing and potential forwarding is done according to the
specification for that PFP type. If the PFP type specification does specification for that PFP type. If the PFP type specification does
not specify any particular forwarding rules, the message is forwarded not specify any particular forwarding rules, the message is forwarded
out of all interfaces with PIM neighbors (including the interface it out of all interfaces with PIM neighbors (including the interface it
is received on). is received on).
2.2.3. Processing messages with unknown PFP type 3.2.3. Processing messages with unknown PFP type
If the PFP type is unknown, the message MUST be dropped if the If the PFP type is unknown, the message MUST be dropped if the
Unknown-No-Forwarding bit is set. If the bit is not set, the message 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 is forwarded out of all interfaces with PIM neighbors (including the
interface it is received on). interface it is received on).
3. 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.
For PFP Type 0 the U-bit MUST NOT be set. This means that routers 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. not supporting PFP Type 0 would still forward the message.
3.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 19 skipping to change at page 8, line 9
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 [RFC4601].
3.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 Mesage, 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 [RFC4601]. After it is decided that
a register needs to be sent, the SG is not registered via the PIM SM a register needs to be sent, the SG is not registered via the PIM SM
register procedures, but the SG mapping is included in an SG message. register procedures, but the SG mapping is included in an SG message.
skipping to change at page 7, line 45 skipping to change at page 8, line 35
long as the multicast source is active, similar to how PIM registers long as the multicast source is active, similar to how PIM registers
are periodically sent. The default announcement period is 60 are periodically sent. The default announcement period is 60
seconds, which means that as long as the source is active, it is seconds, which means that as long as the source is active, it is
included in an SG message originated every 60 seconds. The holdtime included in an SG message originated every 60 seconds. The holdtime
for the source is by default 210 seconds. Other values can be for the source is by default 210 seconds. Other values can be
configured, but the holdtime must be larger than the announcement configured, but the holdtime must be larger than the announcement
period. It is RECOMMENDED to be 3.5 times the announcement period. period. It is RECOMMENDED to be 3.5 times the announcement period.
Note that as a special case a source MAY be announced with a holdtime Note that as a special case a source MAY be announced with a holdtime
of 0 to indicate that the source is no longer active. of 0 to indicate that the source is no longer active.
3.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. If there are directly connected receivers
for that group this router should send PIM (S,G) joins for all the SG for that group 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. The SG mappings are kept alive
for as long as the holdtimer for the source is running. Once the for as long as the holdtimer for the source is running. Once the
holdtimer expires a PIM router SHOULD send a PIM (S,G) prune to holdtimer expires a PIM router SHOULD send a PIM (S,G) prune to
remove itself from the tree. Note that a holdtime of 0 has a special remove itself from the tree. Note that a holdtime of 0 has a special
meaning. It is to be treated as if the source just expired, causing meaning. It is to be treated as if the source just expired, causing
a prune to be sent and state to be removed. Source information MUST a prune to be sent and state to be removed. Source information MUST
not be removed due to it being omitted in a message. For instance, not be removed due to it being omitted in a message. For instance,
if there are a large number of sources for a group, there may be if there are a large number of sources for a group, there may be
multiple SG messages for the same group, each message containing a multiple SG messages for the same group, each message containing a
different list of sources. different list of sources.
3.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 native SPT tree from the RP to the
source. The register packets received on the RP are decapsulated and source. The register packets received on the RP are decapsulated and
forwarded down the shared tree to the LHRs. As soon as an SPT tree forwarded down the shared tree to the LHRs. As soon as an SPT tree
is built, multicast packets would flow natively over the SPT to the is built, multicast packets would flow natively over the SPT to the
RP or LHR and the register process would stop. The PIM register RP or LHR and the register process would stop. The PIM register
process ensures packet delivery until an SPT tree is in place process ensures packet delivery until an SPT tree is in place
reaching the FHR. If the packets were not unicast encapsulated to reaching the FHR. If the packets were not unicast encapsulated to
the RP they would be dropped by the FHR until the SPT is setup. This the RP they would be dropped by the FHR until the SPT is setup. This
skipping to change at page 9, line 12 skipping to change at page 10, line 5
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 tree before the host starts sending which would avoid packet
loss. The SG mappings announced by [I-D.ietf-magma-msnip] can be loss. The SG mappings announced by [I-D.ietf-magma-msnip] can be
advertised directly in SG messages, allowing a very nice integration advertised directly in SG messages, allowing a very nice integration
of both proposals. The life time of the SPT is not driven by the of both proposals. The life time of the SPT is not driven by the
liveliness of Multicast data packets (which is the case with PIM SM), liveliness of Multicast data packets (which is the case with PIM SM),
but by the announcements driven via [I-D.ietf-magma-msnip]. This but by the announcements driven via [I-D.ietf-magma-msnip]. This
will also prevent packet loss due to bursty sources. will also prevent packet loss due to bursty sources.
3.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 9, line 34 skipping to change at page 10, line 27
The solution described in this document does not suffer from that The solution described in this document does not suffer from that
problem. If a network becomes partitioned and new sources become problem. If a network becomes partitioned and new sources become
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.
4. 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 may be a concern that rogue devices can inject
packets that are flooded throughout a domain. PFP packets SHOULD packets that are flooded throughout a domain. PFP packets SHOULD
only be accepted from a PIM neighbor. Deployments may use mechanisms only be accepted from a PIM neighbor. Deployments may use mechanisms
for authenticating PIM neighbors. for authenticating PIM neighbors.
5. 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 allocated 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 allocated to the "Source Group Holdtime" TLV. The
allocation procedures are yet to be determined. allocation procedures are yet to be determined.
6. 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.
7. References 8. References
7.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, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[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, January 2008.
7.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, August 2006.
[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, October 2007.
[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
 End of changes. 20 change blocks. 
39 lines changed or deleted 56 lines changed or added

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