Network Working Group IJ. Wijnands, Ed. Internet-Draft S. Venaas Intended status: Standards Track Cisco Systems, Inc. Expires: December 24, 2012 M. Brig Aegis BMD Program Office June 22, 2012 PIM source discovery via BSR draft-wijnands-pim-source-discovery-bsr-01 Abstract PIM Sparse-Mode use a Rendezvous Point (RP) and shared trees to forward multicast packets to Last Hop Routers (LHR). After the first 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 proposes a solution to support PIM Sparse Mode (SM) without the need for PIM registers, RPs or shared trees. Multicast source information is distributed via Bootstrap Router [RFC5059] messages and flooded throughout the Multicast domain. By removing the 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 24, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Wijnands, et al. Expires December 24, 2012 [Page 1] Internet-Draft PIM source discovery via BSR June 2012 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Wijnands, et al. Expires December 24, 2012 [Page 2] Internet-Draft PIM source discovery via BSR June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Source to Group Mappings via BSR . . . . . . . . . . . . . . . 5 2.1. Originating SG BSR messages . . . . . . . . . . . . . . . 5 2.2. Forwarding SG BSR messages . . . . . . . . . . . . . . . . 5 2.3. Processing SG BSR messages . . . . . . . . . . . . . . . . 5 3. The first packets and bursty sources . . . . . . . . . . . . . 5 4. Resiliency to network partitioning . . . . . . . . . . . . . . 6 5. Fragmentation of BSR messages . . . . . . . . . . . . . . . . 7 6. Bootstrap Source message format . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Wijnands, et al. Expires December 24, 2012 [Page 3] Internet-Draft PIM source discovery via BSR June 2012 1. Introduction PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to forward multicast packets to Last Hop Routers (LHR). After the first 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 proposes a solution to support PIM Sparse Mode (SM) without the need for PIM registers, RPs or shared trees. Multicast source information is distributed via Bootstrap Router [RFC5059] messages and flooded throughout the Multicast domain. By removing the need for RPs and shared trees, the PIM-SM procedures are simplified, improving router operations, management and making the protocol more robust. BSR provides an infrastructure to advertise 'RP mappings' to all the routers in the Multicast network via Reverse Path Forwaring (RPF). This document proposes to use BSR to advertise Source Group (SG) mappings from the First Hop Router (FHR) to all the LHRs. BSR seems like a good fit since its already designed to distribute 'mappings' through out the multicast network. The requirements for distributing SG mappings seems very close to RP mappings, for that reason there seems no need to invent a new protocol. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Terminology RP: Rendezvous Point. BSR: Bootstrap Router. RPF: Reverse Path Forwarding SPT: Shortest Path Tree. FHR: First Hop Router, directly connected to the Source. LHR: Last Hop Router, directly connected to the receiver. SG Mapping: Multicast source to group mapping. SG BSR message: A BSR message containing a source to group mapping. Wijnands, et al. Expires December 24, 2012 [Page 4] Internet-Draft PIM source discovery via BSR June 2012 2. Source to Group Mappings via BSR A Candidate Bootstrap (C-BSR) router is typically a router which is configured to be a BSR. Multiple C-BSR may be configured in the network and an election procedure is applied to select the Elected BSR (E-BSR) router. The E-BSR router is the router that is responsible for distributing the Group to RP mappings. See [RFC5059] section 3.1 for more details. In order to distribute Source to Group (SG) mappings, there is no need to elect an E-BSR router. 2.1. Originating SG BSR messages Each FHR that is directly connected to an active multicast source becomes the E-BSR for that SG mapping. How a multicast router discovers the source of the multicast packet and when it considers it self the FHR follows the same procedures as the 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 register procedures, but the SG mapping is distributed via a BSR message. Note, only the SG mapping is distributed in the BSR message, not the entire packet as would have been done with a PIM register. The router originating the BSR messages includes its own address in the BSR message. The BSR messages are periodically sent for as long as the multicast source is active, similar to how PIM registers are periodically sent. The timer and timeout values described in [RFC5059] apply here as well. 2.2. Forwarding SG BSR messages The forwarding of BSR messages follows the same procedures as documented in [RFC5059] section 3.4 and 3.5. 2.3. Processing SG BSR messages A router that receives a SG BSR messages should parse the SG BSR message and store the SG mappings with a holdtimer started with the advertised 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 mappings advertised in the BSR message. The SG BSR mappings is kept alive for as long as the holdtimer for the source is running. Once the holdtimer expired a PIM (S,G) prune must be sent to remove itself from the tree. 3. The first packets and bursty sources 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 Wijnands, et al. Expires December 24, 2012 [Page 5] Internet-Draft PIM source discovery via BSR June 2012 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 is built, multicast packets would flow natively over the SPT to the RP or LHR and the register process would stop. The PIM register process bridges the gap between how long it takes to build the SPT tree to the FHR. If the packets would not be unicast encapsulated to the RP they would be dropped by the FHR until the SPT is setup. This functionality is important for applications where the first packet(s) must be received for the application to work correctly. An other reason would be for bursty sources. If the application sends out a multicast packet every 4 minutes (or longer), the SPT is torn down (typically after 3:30 minutes of inactivity) before the next packet is forwarded down the tree. This will cause no multicast packet to ever be forwarded. A well behaved application should really be able to deal with packet loss since IP is a best effort based packet delivery system. But in reality this is not always the case. With the procedures proposed in this draft the packet(s) received 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 applications sensitive for the delivery of the first packet this proposal would not be very applicable. This proposal is mostly useful for applications that don't have strong dependency on the first packet(s) and have a constant data rate, like video distribution for example. For applications with strong dependency on the first packet(s) we recommend using PIM Bidir [RFC5015] or SSM [RFC4607]. The protocol operations are much simpler compared to PIM SM, it will cause less churn in the network and both guarantee best effort delivery for the first packet(s). An other 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 tree before the host starts sending which would avoid packet loss. The SG mappings announced by [I-D.ietf-magma-msnip] can be advertised directly into BSR, allowing a very 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. Resiliency to network partitioning In a PIM SM deployment where the network becomes partitioned, due to 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 Wijnands, et al. Expires December 24, 2012 [Page 6] Internet-Draft PIM source discovery via BSR June 2012 that partition will not be able to register to the RP and receivers within that partition are not able to receive the traffic. Ideally you would want to have a candidate RP in each partition, but you 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 being a candidate RP. This would increase the operational complexity of the network. The solution described in this document does not suffer from that problem. If a network becomes partitioned and new sources become active, the receivers in that partitioned will receive the BSR SG Mappings and join the source tree. Each partition works independently of the other partition(s) and will continue to have access to sources within that partition. As soon as the network heals, the SG Mappings are re-flooded into the other partition(s) and other receives can join to the newly learned sources. 5. Fragmentation of BSR messages [RFC5059] defines procedures to fragment BSR messages if the number of group to RP mappings is too large and the packet exceeds the MTU size. Its important for PIM to have all the RP mappings before it applies the selection process. Missing mappings may cause the wrong RP to be selected. Using BSR to distribute SG mappings we don't have this problem. There is no reason to have all the source before joining the tree. There is no selection process applied to the SG mappings, all the known SG mappings should be joined by PIM. For that reason there is no special fragmentation support defined for SG mappings. 6. Bootstrap Source message format Wijnands, et al. Expires December 24, 2012 [Page 7] Internet-Draft PIM source discovery via BSR June 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |N| Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FHR Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Count | Src Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address 1 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address 2 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address m (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address 2 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Count | Src Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address 1 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address 2 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address m (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address n (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Count | Src Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address 1 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address 2 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address m (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wijnands, et al. Expires December 24, 2012 [Page 8] Internet-Draft PIM source discovery via BSR June 2012 PIM Version: Reserved, Checksum Described in [RFC4601]. Type: PIM Message Type. Value (pending IANA) for a Bootstrap Source message [N]o-Forward bit: When set, this bit means that the Bootstrap message fragment is not to be forwarded. FHR Address: The address of the FHR router for the domain. This can be any address assigned to this router, but MUST be routable in the domain to allow successful forwarding (just like BSR address). The format for this address is given in the Encoded- Unicast address in [RFC4601]. Group Address 1..n: The address of the bootstrap router for the domain. The format for this address is given in the Encoded- Unicast address in [RFC4601]. Src Count How many unicast encoded sources address encodings follow. Src Holdtime: The Holdtime (in seconds) for the corresponding source(s). Src Address: The source address for the corresponding group range. The format for these addresses is given in the Encoded-Unicast address in [RFC4601]. 7. Security Considerations The security considerations are no different from what is documented in [RFC5059]. 8. IANA considerations This document requires the assignment of a new code point from the IANA managed registry "PIM Message Types" called "Bootstrap Source Mapping". Wijnands, et al. Expires December 24, 2012 [Page 9] Internet-Draft PIM source discovery via BSR June 2012 9. Acknowledgments The authors would like to thank Arjen Boers for contributing to the initial idea and Yiqun Cai for his comments on the draft. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008. 10.2. Informative References [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [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 IJsbrand Wijnands (editor) Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com Wijnands, et al. Expires December 24, 2012 [Page 10] Internet-Draft PIM source discovery via BSR June 2012 Stig Venaas Cisco Systems, Inc. Tasman Drive San Jose CA 95134 USA Email: stig@cisco.com Michael Brig Aegis BMD Program Office 17211 Avenue D, Suite 160 Dahlgren VA 22448-5148 USA Email: michael.brig@mda.mil Wijnands, et al. Expires December 24, 2012 [Page 11]