Internet DRAFT - draft-pfister-pim-border-proxy
draft-pfister-pim-border-proxy
Network Working Group P. Pfister
Internet-Draft
Intended status: Informational October 27, 2014
Expires: April 30, 2015
Protocol Independent Multicast Border Proxying
draft-pfister-pim-border-proxy-00
Abstract
This document describes an extension to the Protocol Independent
Multicast (PIM) multicast routing protocol that enables PIM proxying
from PIM domains toward other multicast domains. It relies on PIM
Proxies located on domain borders and Proxy Controllers which can be
located anywhere. This document describes how subscriptions can be
proxied toward domain's border interfaces using MLDv2 and IGMPv3, but
other protocols could be used as well. Once multicast traffic is
received on a proxied interface, it can be forwarded as if originated
by a directly connected source.
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
carefully, as they describe your rights and restrictions with respect
Pfister Expires April 30, 2015 [Page 1]
Internet-Draft PIM Proxy October 2014
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. Protocol Specifications . . . . . . . . . . . . . . . . . . . 3
2.1. Proxy Controller Behavior . . . . . . . . . . . . . . . . 3
2.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 3
2.3. PIM Proxy Message format . . . . . . . . . . . . . . . . 4
2.3.1. Message Header . . . . . . . . . . . . . . . . . . . 4
2.3.2. State Update Message . . . . . . . . . . . . . . . . 4
2.3.3. Keep Alive Message . . . . . . . . . . . . . . . . . 5
3. Different proxy types . . . . . . . . . . . . . . . . . . . . 6
3.1. IGMP/MLD proxy . . . . . . . . . . . . . . . . . . . . . 6
3.2. IGMP/MLD controller . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8
Appendix B. Discussion . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Protocol Independent Multicast (PIM - [RFC4601]) routing protocol
initially reacts to two different event types: multicast traffic
reception from a connected source, and local multicast subscription
(MLD or IGMP) state change on a connected link. This approach works
when the network consists of a single PIM multicast domain, but does
not when border routers are connected to different multicast domains.
In such situations, the border routers need to be told to which group
they should subscribe to on their egress interfaces before multicast
traffic can be received.
This document defines PIM Proxy's and PIM Proxy Controller's
behavior. There may be one or multiple instances of each in the same
PIM domain. Each controller opens a TCP connection toward every
proxy it wants to interact with and sends updates every time the
Proxy's state should be updated.
In PIM-SM domains, one possible application of this extension
consists in using the Rendezvous as a PIM Proxy Controller for all
border routers, which in turn reflects network-wide subscription
Pfister Expires April 30, 2015 [Page 2]
Internet-Draft PIM Proxy October 2014
state on domain's external interfaces using MLDv2 [RFC3810] or IGMPv3
[RFC3376]. In PIM-BIDIR domains, the same approach could be used,
but would not support Source-Specific multicast. Instead, every
router can reflect the local subscription state of links on which it
is the Designated Forwarder.
This extension was designed in order to allow ISP originated traffic
to reach subscribed hosts located inside a home network
[I-D.ietf-homenet-arch]. Input from PIM and Homenet working group
regarding other possible solutions enabling multicast routing in home
networks are very welcome.
2. Protocol Specifications
This protocol allows controllers to push PIM subscription state
toward proxies. The state a given controller pushes toward a given
proxy may differ depending on the proxy, the local configuration, and
may not reflect the local MLD or IGMP querier state. It is an
arbitrary choice and depends on the purpose of the proxy.
The following state is maintained for every established TCP
connection and every PIM Group/Source state ((*,G), (S,G,rpt),
(S,G)). Although this is implementation specific, the generic
behavior would consist in keeping the state for every Group/Source
pair in their respective Encoded-Group and Encoded-Source formats
(e.g. different states whether [B]idir bit is set or not).
Mode: One of { "NoInfo", "Join", "Prune" }.
If no state is stored for a given Group/Source pair, it is equivalent
to the "NoInfo" state. Similarly, after being switched to "NoInfo"
state, a stored state may be removed.
2.1. Proxy Controller Behavior
A proxy controller opens a TCP connection with every proxy it wants a
peering with. When a new connection is opened, the complete state is
first transmitted in order to synchronize the proxy with the
controller's state. Then, each time some state is changed, an update
is sent through the TCP connection.
2.2. Proxy Behavior
A proxy MUST listen on port PIM_PROXY_TCP_PORT for incoming TCP
connections. When a new connection is established, a new
subscription state is created.
Pfister Expires April 30, 2015 [Page 3]
Internet-Draft PIM Proxy October 2014
2.3. PIM Proxy Message format
2.3.1. Message Header
PIM Proxy messages are transported over TCP and make use of the
following TLV format.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 1
Type:
One of the defined message types.
Length:
The byte length of the value.
Value:
The value.
2.3.2. State Update Message
PIM Proxy State Update messages use the following format.
Pfister Expires April 30, 2015 [Page 4]
Internet-Draft PIM Proxy October 2014
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 = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address n (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address m (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State |
+-+-+-+-+-+-+-+-+ ...
Figure 2
Type:
State Update message type (1)
Number of Sources:
The number of sources associated with the group.
State:
The state the controller wants the proxy to save for the given
group/source pair.
* NoInfo (0)
* Join (1)
* Prune (2)
Upon reception of a State Update message, a proxy will switch the
state associated with every Group/Source pairs included in the
message to the state specified in the message.
2.3.3. Keep Alive Message
Keep Alive messages are used to keep the TCP connection open and have
the following format (Most current TCP implementations support TCP
keep-alives, but not all. The Keep-Alive TLV is specified because
keeping the connection open is a requirement for not losing state).
Pfister Expires April 30, 2015 [Page 5]
Internet-Draft PIM Proxy October 2014
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 = 2 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
3. Different proxy types
This document does not intend to specify all the possible proxy
behavior. Requests could be translated into MLD and IGMP, relayed
toward another separated PIM domain, translated into another
multicast delivery protocol, or even be used for monitoring purposes.
Any proxy behavior CAN be overridden by local policies. For
instance, proxying behavior may depend on the group's scope or
firewalling rules.
Once multicast traffic is requested on an egress interface, PIM
should be used as usual in order to decide whether incoming traffic
should be forwarded on an ingress interface.
3.1. IGMP/MLD proxy
This section describes how to translate a PIM Proxy group's state
toward an MLDv2/IGMPv3 listener state. It can be used for both PIM-
SM and PIM-BIDIR (states are considered regardless of the BIDIR bit).
According to PIM-SM and PIM-BIDIR specifications, (*,G) or (S,G) can
only be in state "NoInfo" or "Join", and (S,G,rpt) can only be in
state "NoInfo" or "Prune".
If (*,G) is set to "Join", the MLDv2/IGMPv3 group state should be set
to "Exclude" and the Exclude Sources List should contain all sources
S for which (S, G, rpt) is set to "Prune" and (S,G) is set to
"NoInfo".
If (*,G) is set to "NoInfo", the MLDv2/IGMPv3 group state should be
set to "Include" and the Include Sources List should contain all
sources S for which (S, G) is set to "Join".
When multiple controllers are pushing state to the same proxy, the
algorithm detailed in MLDv2 and IGMPv3 specifications should be used
in order to merge the different requests.
Pfister Expires April 30, 2015 [Page 6]
Internet-Draft PIM Proxy October 2014
3.2. IGMP/MLD controller
This section describes how to translate an MLDv2/IGMPv3 querier state
into a PIM subscription state.
If the group's MLDv2/IGMPv3 state is "Include", the PIM state
consists in (S,G) states set to "Join" for all S in the MLDv2/IGMPv3
source include list.
If the group's MLDv2/IGMPv3 state is "Exclude", the (*,G) state is
set to "Join" and all (S,G,rpt) for S in the MLDv2/IGMPv3 source
exclude list are set to "Prune".
4. Security Considerations
PIM Proxy messages are sent multiple hops away and are used in order
to control other router's behavior. Attackers could open a
connection from outside or inside the network and trigger multicast
requests and forwarding. TLS or IPSec could be used in order to
secure the connection. If not, connections should at least be
filtered based on the controller's IP source address.
5. IANA Considerations
IANA is kindly requested to:
o Reserve a TCP port number for PIM Proxies.
o Create a new registry for PIM Proxy TLVs.
o Create a new registry for Group/Source states.
6. References
6.1. Normative References
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Pfister Expires April 30, 2015 [Page 7]
Internet-Draft PIM Proxy October 2014
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
6.2. Informative References
[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.
Appendix A. Acknowledgments
The author would like to thank Steven Barth and Mohammed Hawari for
their help in the protocol design and implementation process, as well
as Mark Townsley, Stig Venaas, Markus Stenberg and IJsbrand Wijnands
for their useful input.
Appendix B. Discussion
Another message type we would probably need is a "Traffic Present"
message. Sent from the Proxy toward the Controller, it would let the
controller take actions when the same traffic is provided by two
different border routers. But that gets inefficient when there are
more than one controller.
Author's Address
Pierre Pfister
Paris
France
Email: pierre@darou.fr
Pfister Expires April 30, 2015 [Page 8]
