| Network Working Group | P. Pfister |
| Internet-Draft | |
| Intended status: Standards Track | October 27, 2014 |
| Expires: April 30, 2015 |
Multicast enabled Home Network using PIM-SSBIDIR and HNCP
draft-pfister-homenet-multicast-00
This document specifies a possible solution enabling multicast routing in a home network. It relies on the Source-Specific Bidirectional variant of the Protocol Independent Multicast routing protocol (PIM-SSBIDIR). HNCP is used to elect the Rendezvous Point address and a Proxy Controller connected to the Rendezvous Point Link. Additionally, PIM-SSBIDIR routers behavior is slightly modified on the Rendezvous Point Link so that the Proxy Controller may know the home-wide subscription state. Note that this document defines one single working solution to the stated problem: Inputs regarding other possibilities are welcome.
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 April 30, 2015.
Copyright (c) 2014 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 (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.
IP multicast is used not only for link-local communications but also for site-local exchanges (UPnP [UPnP] or TV over IP). Additionally, we can expect new connected objects will make use of this technique for diverse purposes. Most link types like Ethernet or 802.11 support link-local multicast natively, but a multicast routing protocol is required when multiple links are present. The Protocol Independent Multicast [RFC4601] is one of the most widely used multicast routing protocol. Unfortunately, home networks have some peculiarities that makes it unsuitable without changes.
This document lists the specificities of home networks regarding multicast, the problems resulting from these peculiarities and specifies how homenet routers must behave in order to enable multicast routing for both in-home and ISP originated traffic in multi-homed environments.
The solution makes use of the Source-Specific Bidirectional variant of the Protocol Independent Multicast routing protocol (PIM-SSBIDIR - [pim-ssbidir]) for routing multicast traffic inside the home, and PIM Border Proxies ([pim-border-proxy]) for subscribing on all uplink interfaces. Two new HNCP TLVs are defined. One is used in the Rendezvous Point Address (RPA) and Proxy Controller election process, the other is used for advertising PIM Border Proxies. In addition, PIM-SSBIDIR behavior is slightly modified on the RP Link allowing the Proxy Controller, connected on the RP Link, to acquire the home-wide subscription state.
This document specifies a functional solution enabling multicast routing in multi-homed home networks. Inputs regarding other possibilities are very welcome and expected, so the best design may be adopted.
Current home networks usually consist of a single link and therefore support link-local multicast using MLDv2 [RFC3810] or IGMPv3 [RFC3376] for both all-source (ASM) and source-specific (SSM) multicast. Future home networks ([I-D.ietf-homenet-arch]) will consist of multiple links, which means multicast routing will be required.
This section discusses home network requirements and problems related to multicast routing.
Future home networks should at least provide the same multicast features as the existing home networks.
On top of that, home network environments add the following constraints, defined in the Homenet architecture document.
This document makes no assumptions on the technique used by ISPs to provide multicast traffic. It allows border routers to act as PIM Border Proxies, translating the home-wide subscription state toward every multicast enabled home uplink. Border router default behavior SHOULD consist in using MLDv2 and IGMPv3 on all uplink interfaces. Similarly, multicast enabled ISPs SHOULD listen to MLDv2 and IGMPv3 subscriptions coming from CPEs, and provide multicast traffic accordingly.
Note that this document doesn't preclude the use of different techniques. For example, an ISP-provided CPE may be specifically configured to translate in-home multicast subscriptions into PIM requests on the ISP link. But this is outside the scope of this document.
Both PIM Bootstrap Mechanism (PIM BSR - [RFC5059]) and the Homenet Configuration Protocol (HNCP - [I-D.ietf-homenet-hncp]) could be used for autoconfiguration purposes. As HNCP support is already required in all homenet routers, this document proposes to use it instead of its PIM equivalent.
PIM-SM [RFC4601], PIM-BIDIR [RFC5015] and PIM-SSM were designed to function in single routed domains. Extensions allow multiple domains to be connected one with each other, but they all require specific PIM interactions between the domains, and a non-ambiguous knowledge of the next hop router for any multicast source. Given homenet constraints, we encounter the two following problems.
Initially, PIM reacts to two types of events. MLDv2/IGMPv3 subscriptions and multicast traffic origination. As receiving traffic from the ISP requires a subscription to happen first, border routers need some knowledge of the home-wide subscription state. In a single-homed network, the border router could be the RP, but in a multi-homed network, this subscription information must be shared between all border routers.
In multi-homed networks, routers have multiple default routes (one for each uplink). Unicast routing is achieved by looking at both source and destination addresses, but this technique can't be used when forwarding Join/Prune messages.
When multiple default routes point to different next-hop routers, Source-Specific Join/Prune messages' next-hop cannot be reliably determined. A possible but not very scalable solution would consist in letting all the routers dynamically know where are every sources located. This document proposes to makes use of PIM-SSBIDIR instead.
In order to deliver multicast traffic to subscribed devices, all homenet routers MUST implement PIM-SSBIDIR as well as the specifications presented in the present document.
Whenever the present document doesn't conform to PIM specifications, behavior and configuration values described in this document take precedence.
PIM-SSBIDIR and PIM-BIDIR both rely on the mapping between group ranges and Rendezvous Point Addresses. In PIM-SSBIDIR a Rendezvous point address doesn't need to belong to an actual router but rather identify the Rendezvous Point Link. This is still true in the present document, but in addition to the RP Address, HNCP is used to elect a single Proxy Controller, directly connected to the RP Link.
In order to elect the RPA and Proxy Controller, the following HNCP TLV is defined.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: PIM-RPA-CANDIDATE | Length: 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 RP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM RPA Candidate TLV
The Rendezvous Point Address is chosen among all the advertised PIM RPA Candidate TLVs. The TLV with the highest priority is chosen first. In case of tie, the highest RPA address is preferred. The elected Proxy Controller is the router with the highest router ID advertising the elected PIM RPA Candidate TLV.
A router MUST start advertising a PIM RPA Candidate TLV (and thus candidate as Proxy Controller) whenever one of the two following condition is met.
A router MUST stop advertising a PIM RPA Candidate TLV whenever another advertised PIM RPA Candidate TLV takes precedence over its own one.
A router MUST NOT advertise more than one PIM RPA Candidate TLV. An advertised PIM RPA Candidate TLV MUST contain an IPv6 address known by all home routers and associated with a directly connected link. A Priority value of 0 SHOULD be used, unless stated otherwise by dynamic (DHCP, netconf, ...) or static (file) configuration.
When the RP Address is not valid anymore, the elected Proxy Controller MUST replace the advertised RP Address with a new, valid, RP Address. Such an event SHOULD be avoided. Therefore, an address with a long valid lifetime SHOULD be preferred.
All routers with at least one uplink interface SHOULD behave as PIM Border Proxies, as specified in [pim-border-proxy], unless specified otherwise by static or dynamic configuration. They SHOULD proxy the received subscription state onto uplink interfaces for all groups of global scope.
Multicast proxying is a local operation subject to numerous optimizations and configuration, particularly on ISP-provided CPEs. The following list specifies the default behavior.
In addition, PIM Border Proxy routers MUST advertise the following TLV in their HNCP Node State.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: PIM_BORDER_PROXY | Length: 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Proxy Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Border Proxy TLV
The elected Proxy Controller must behave as specified in [pim-border-proxy]. It MUST establish one peering for each address specified in PIM Border Proxy TLVs. It MUST reflect the home-wide subscription state toward all border proxies, computed based on all per-interface PIM downstream state machines and on-link local subscriptions, as if the RP was reachable on a virtual uplink interface.
This section specifies the changes made to PIM-SSBIDIR, required in the homenet context.
PIM-SSBIDIR always forwards the multicast traffic toward the RP Link and therefore never sends Join/Prune packets on the RP Link nor requires routers to listen to local subscriptions on the RP Link. But the elected Proxy Controller needs to know the home-wide subscription state. Which is why router's behavior is modified on the RP Link.
All routers MUST operate the (*,G), (S,G) and (S,G,rpt) upstream state machines on all their interfaces, including the RP Link. On the RP Link, no DF Election process takes place. When sending Join/Prune messages on the RP Link, the DF address is replaced with the RP Address.
The elected Proxy Controller MUST as well operate the downstream per-interface (*,G), (S,G) and (S,G,rpt) state machines on the RP Link, as well as enable multicast querying. Other routers connected to the RP Link SHOULD enable both downstream state machines and multicast querying as well in order to improve transition whenever the Proxy Controller would change.
PIM is an unreliable protocol. When a Join message is lost, the protocol waits for the next one, which by default comes after 60 seconds. A very typical use case for IP multicast is TV over IP, but we can't expect a user to wait 60 seconds when it changes the TV channel. Therefore, the default period between Join/Prune messages is reduced.
Similarly, PIM sends Hello messages every 30 seconds, which means dead neighbor detection occurs after 90 seconds. Therefore, the Hello period is reduced.
This document mostly relies on HNCP and PIM-SSBIDIR and therefore doesn't add much new threats.
The RP election process could be attacked whenever HNCP is not protected. Similarly, an attacker could advertise numerous PIM Border Proxy TLVs as a Deny of Service attack vector.
In order to operate securely, both HNCP and PIM-SSBIDIR should be secured.
IANA is kindly requested to reserve two new HNCP TLV identifiers:
| [RFC3810] | Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. |
| [RFC3376] | Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. |
| [I-D.ietf-homenet-hncp] | Stenberg, M. and S. Barth, "Home Networking Control Protocol", Internet-Draft draft-ietf-homenet-hncp-01, June 2014. |
| [pim-ssbidir] | Pierre Pfister, "Source Specific support for Bidirectional Protocol Independent Multicast", October 2014. |
| [pim-border-proxy] | Pierre Pfister, "Protocol Independent Multicast Border Proxying", October 2014. |
| [RFC4601] | Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. |
| [RFC5015] | Handley, M., Kouvelas, I., Speakman, T. and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007. |
| [RFC5059] | Bhaskar, N., Gall, A., Lingard, J. and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008. |
| [UPnP] | UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001. |
| [I-D.ietf-homenet-arch] | Chown, T., Arkko, J., Brandt, A., Troan, O. and J. Weil, "IPv6 Home Networking Architecture Principles", Internet-Draft draft-ietf-homenet-arch-17, July 2014. |
The author would like to thank Steven Barth and Mohammed Hawari for their help in the specification and implementation process, as well as Mark Townsley, Stig Venaas, IJsbrand Wijnands and Markus Stenberg for their useful inputs.