draft-ietf-pim-source-discovery-bsr-05.txt   draft-ietf-pim-source-discovery-bsr-06.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: May 4, 2017 M. Brig Expires: September 11, 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)
October 31, 2016 March 10, 2017
PIM flooding mechanism and source discovery PIM flooding mechanism and source discovery
draft-ietf-pim-source-discovery-bsr-05 draft-ietf-pim-source-discovery-bsr-06
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
that provides a way to support PIM Sparse Mode (SM) without the need mechanism that provides a way to support PIM Sparse Mode (SM) without
for PIM registers, RPs or shared trees. Multicast source information the need for PIM registers, RPs or shared trees. Multicast source
is flooded throughout the multicast domain using a new generic PIM information is flooded throughout the multicast domain using a new
flooding mechanism. This allows last hop routers to learn about new generic PIM flooding mechanism. This allows last hop routers to
sources without receiving initial data packets. learn about new sources without receiving initial data packets.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 May 4, 2017. This Internet-Draft will expire on September 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
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. PFM message format . . . . . . . . . . . . . . . . . . . 4 3.1. PFM message format . . . . . . . . . . . . . . . . . . . 5
3.2. Processing PFM messages . . . . . . . . . . . . . . . . . 5 3.2. Processing PFM messages . . . . . . . . . . . . . . . . . 6
3.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 5 3.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 6
3.2.2. Processing and forwarding of PFM messages . . . . . . 6 3.2.2. Processing and forwarding of PFM messages . . . . . . 6
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 . . . . . . . . . . . . . . . . 7
4.2. Originating PFM messages . . . . . . . . . . . . . . . . 7 4.2. Originating PFM messages . . . . . . . . . . . . . . . . 8
4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 8 4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 10
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 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 mechanism that provides a way to support PIM Sparse defines a new mechanism that provides a way to support PIM Sparse
Mode (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. By removing the
defined in this document, and is modeled after the Bootstrap Router need for RPs and shared trees, the PIM-SM procedures are simplified,
mechanism [RFC5059]. By removing the need for RPs and shared trees, improving router operations, management and making the protocol more
the PIM-SM procedures are simplified, improving router operations, robust. Also the data packets are only sent on the SPTs, providing
management and making the protocol more robust. Also the data 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].
1.2. Terminology 1.2. Terminology
RP: Rendezvous Point. RP: Rendezvous Point
BSR: Bootstrap Router. BSR: Bootstrap Router
RPF: Reverse Path Forwarding. RPF: Reverse Path Forwarding
SPT: Shortest Path Tree. SPT: Shortest Path Tree
FHR: First Hop Router, directly connected to the source. FHR: First Hop Router, directly connected to the source
LHR: Last Hop Router, directly connected to the receiver. LHR: Last Hop Router, directly connected to the receiver
PFM: PIM Flooding Mechanism. PFM: PIM Flooding Mechanism
PFM-SA: PFM Source Announcement. PFM-SA: PFM Source Announcement
SG Mapping: Multicast source to group mapping. 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. The network has frequent
frequent topology changes and link or router failures, PIM-SM with RP topology changes, including frequest link or router failures.
election is found to be too slow. With PIM-DM, issues were observed Previously existing mechanisms like PIM-SM and PIM-DM were tested.
with new multicast sources starving low bandwidth links even when
there are no receivers, in some cases such that there was no With PIM-SM the existing RP election mechanisms were found to be too
bandwidth left for prune message. For the tests, all routers were slow. With PIM-DM, issues were observed with new multicast sources
configured to send PFM-SA for directly connected source and to cache starving low bandwidth links even when there are no receivers, in
received announcements. Applications such as SIP with multicast some cases such that there was no bandwidth left for prune message.
subscriber discovery, multicast voice conferencing, position tracking
and NTP were successfully tested. The tests went quite well. For the PFM-SA prototype tests, all routers were configured to send
Packets were rerouted as needed and there were no unnecessary PFM-SA for directly connected source and to cache received
forwarding of packets. Ease of configuration was seen as a plus. 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 3. A generic PIM flooding mechanism
The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used
mechanism for distributing dynamic Group to RP mappings in PIM. It mechanism for distributing dynamic Group to RP mappings in PIM. It
is responsible for flooding information about such mappings is responsible for flooding information about such mappings
throughout a PIM domain, so that all routers in the domain can have throughout a PIM domain, so that all routers in the domain can have
the same information. BSR as defined, is only able to distribute the same information. BSR as defined, is only able to distribute
Group to RP mappings. We are defining a more generic mechanism that Group to RP mappings. We are defining a more generic mechanism that
can flood 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 one can control whether routers should forward
whether routers should forward unsupported data types. For some unsupported data types. For some types of information it is quite
types of information it is quite useful that it can be distributed useful that it can be distributed without all routers having to
without all routers having to support the particular type, while support the particular type, while there may also be types where it
there may also be types where it is necessary for every single router is necessary for every single router to support it. The mechanism
to support it. The mechanism includes an originator address which is includes an originator address which is used for RPF checking to
used for RPF checking to restrict the flooding, and prevent loops, restrict the flooding, and prevent loops, just like BSR. Like BSR,
just like BSR. Just like BSR it is also sent hop by hop. Note that messages are forwarded hop by hop. Note that there is no equivalent
there is no built in election mechanism as in BSR, so there can be to the BSR election mechanism;, there can be multiple originators.
multiple originators. We call this mechanism the PIM Flooding We call this mechanism the PIM Flooding Mechanism (PFM).
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 6, line 20 skipping to change at page 6, line 39
} }
if (PFM.no_forward_bit == 0) { if (PFM.no_forward_bit == 0) {
if (PFM.src_ip_address != if (PFM.src_ip_address !=
RPF_neighbor(PFM.originator_ip_address)) { RPF_neighbor(PFM.originator_ip_address)) {
drop the message silently, optionally log error. drop the message silently, optionally log error.
} }
} else if (more than 60 seconds elapsed since startup)) { } else if (more than 60 seconds elapsed since startup)) {
drop the message silently, optionally log error. drop the message silently, optionally log error.
} }
Note that src_ip_address is the source address in the IP header of
the PFM message. Originator is the originator field inside the PFM
message, and is the router that originated the message. When the
message is forwarded hop by hop, the originator address never
changes, while the source address will be an address belonging to the
router that last forwarded the message.
3.2.2. Processing and forwarding of PFM messages 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, we then for each included TLV performed. If it passes the checks, we then for each included TLV
perform processing according to the specification for that TLV. perform processing according to the specification for that TLV.
After processing, we forward the message. Unless otherwise specified After processing, we forward the message. Unless otherwise specified
by the type specification, the TLVs in the forwarded message are by the type specification, the TLVs in the forwarded message are
identical to the TLVs in the received message. However, if the most identical to the TLVs in the received message. However, if the most
significant bit in the type field is set (the type value is larger significant bit in the type field is set (the type value is larger
skipping to change at page 9, line 32 skipping to change at page 10, line 5
sensitive for the delivery of the first packet this solution would sensitive for the delivery of the first packet this solution would
not be very applicable. This solution is mostly useful for not be very applicable. This solution is mostly useful for
applications that don't have strong dependency on the initial applications that don't have strong dependency on the initial
packet(s) and have a fairly constant data rate, like video packet(s) and have a fairly constant data rate, like video
distribution for example. For applications with strong dependency on distribution for example. For applications with strong dependency on
the initial packet(s) 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
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
Group before sending the data packets. LHRs have time to join the
SPT before the host starts sending which would avoid packet loss.
The SG mappings announced by [I-D.ietf-magma-msnip] can be advertised
directly in SG messages, allowing a nice integration 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), but by the
announcements driven via [I-D.ietf-magma-msnip]. This will also
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.
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
skipping to change at page 11, line 37 skipping to change at page 11, line 41
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>. <http://www.rfc-editor.org/info/rfc5015>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[I-D.ietf-magma-msnip]
Fenner, B., Haberman, B., Holbrook, H., Kouvelas, I., and
S. Venaas, "Multicast Source Notification of Interest
Protocol (MSNIP)", draft-ietf-magma-msnip-06 (work in
progress), March 2011.
Authors' Addresses Authors' Addresses
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
Stig Venaas Stig Venaas
 End of changes. 25 change blocks. 
77 lines changed or deleted 68 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/