Internet DRAFT - draft-pfister-homenet-multicast
draft-pfister-homenet-multicast
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
Abstract
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.
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 April 30, 2015.
Copyright Notice
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
Pfister Expires April 30, 2015 [Page 1]
Internet-Draft homenet Prefixes October 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Specific Problems . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Uplink subscription problem . . . . . . . . . . . . . 4
2.2.2. Uplink source localization problem . . . . . . . . . 4
3. Homenet Multicast Support Specifications . . . . . . . . . . 5
3.1. General Requirements . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Point Address Election Process . . . . . . . . 5
3.3. PIM Border Proxy behavior . . . . . . . . . . . . . . . . 6
3.4. PIM-SSBIDIR changes . . . . . . . . . . . . . . . . . . . 7
3.4.1. Router's behavior on the RP Link . . . . . . . . . . 7
3.4.2. Timing Considerations . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
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.
Pfister Expires April 30, 2015 [Page 2]
Internet-Draft homenet Prefixes October 2014
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.
2. Problem Analysis
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.
2.1. Requirements
Future home networks should at least provide the same multicast
features as the existing home networks.
In-home traffic: Devices inside the home should be able to send and
receive multicast traffic originated inside the home.
ISP to Home traffic: Devices inside the home should be able to
receive multicast traffic coming from an ISP.
Home to ISP traffic: Although traffic originated inside the home
MUST NOT be forwarded on external interfaces by default, it
should not be precluded.
On top of that, home network environments add the following
constraints, defined in the Homenet architecture document.
Autoconfiguration: It must function without human interactions.
Pfister Expires April 30, 2015 [Page 3]
Internet-Draft homenet Prefixes October 2014
Multi-Homing: It must support multiple uplinks and therefore
multiple default routes.
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.
2.2. Specific Problems
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.
2.2.1. Uplink subscription problem
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.
2.2.2. Uplink source localization problem
In multi-homed networks, routers have multiple default routes (one
for each uplink). Unicast routing is achieved by looking at both
Pfister Expires April 30, 2015 [Page 4]
Internet-Draft homenet Prefixes October 2014
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.
3. Homenet Multicast Support Specifications
3.1. General Requirements
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.
3.2. Rendezvous Point Address Election Process
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
Pfister Expires April 30, 2015 [Page 5]
Internet-Draft homenet Prefixes October 2014
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.
o There is no currently advertised PIM RPA Candidate TLV network-
wide.
o All the advertised PIM RPA Candidate TLVs have priority values
lower than the one specified in the router's configuration and it
is specifically stated by configuration that the router should try
overcoming the currently elected RP.
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.
3.3. PIM Border Proxy behavior
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.
o All groups with non-global scope SHOULD be ignored.
Pfister Expires April 30, 2015 [Page 6]
Internet-Draft homenet Prefixes October 2014
o The home-wide subscription state SHOULD be proxied on all uplink
interfaces.
o The uplink default protocols are MLDv2 for IPv6 groups and IGMPv3
for IPv4 groups.
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.
3.4. PIM-SSBIDIR changes
This section specifies the changes made to PIM-SSBIDIR, required in
the homenet context.
3.4.1. Router's behavior on the RP Link
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/
Pfister Expires April 30, 2015 [Page 7]
Internet-Draft homenet Prefixes October 2014
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.
3.4.2. Timing Considerations
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.
t_periodic: Default = 5 secs.
Similarly, PIM sends Hello messages every 30 seconds, which means
dead neighbor detection occurs after 90 seconds. Therefore, the
Hello period is reduced.
Hello_Period: Default = 10 secs.
4. Security Considerations
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.
5. IANA Considerations
IANA is kindly requested to reserve two new HNCP TLV identifiers:
o PIM Border Proxy TLV: PIM_BORDER_PROXY
o PIM RPA Candidate TLV: PIM-RPA-CANDIDATE
Pfister Expires April 30, 2015 [Page 8]
Internet-Draft homenet Prefixes October 2014
6. References
6.1. Normative References
[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", draft-ietf-homenet-hncp-00 (work in progress),
April 2014.
[pim-ssbidir]
Pierre Pfister, "Source Specific support for Bidirectional
Protocol Independent Multicast", October 2014,
<http://tools.ietf.org/html/draft-pfister-pim-ssbidir-00>.
[pim-border-proxy]
Pierre Pfister, "Protocol Independent Multicast Border
Proxying", October 2014, <http://tools.ietf.org/html/
draft-pfister-pim-border-proxy-00>.
6.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.
[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", draft-
ietf-homenet-arch-11 (work in progress), October 2013.
Pfister Expires April 30, 2015 [Page 9]
Internet-Draft homenet Prefixes October 2014
Appendix A. Acknowledgments
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.
Author's Address
Pierre Pfister
Paris
France
Email: pierre@darou.fr
Pfister Expires April 30, 2015 [Page 10]
