Mboned M. Abrahamsson
Internet-Draft T-Systems
Intended status: Informational T. Chown
Expires: January 7, 2017 Jisc
L. Giuliano
Juniper Networks, Inc.
July 6, 2016
Multicast Service Models
draft-acg-mboned-multicast-models-00
Abstract
The draft provides a high-level overview of multicast service and
deployment models, principally the Any-Source Multicast (ASM) and
Source-Specific Multicast (SSM) models, and aims to provoke
discussion of applicability of the models to certain scenarios. This
initial draft is by no means comprehensive. Comments on the initial
content, and what further content would be appropriate, or indeed
whether the draft is of value, are welcomed.
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 January 7, 2017.
Copyright Notice
Copyright (c) 2016 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
Abrahamsson, et al. Expires January 7, 2017 [Page 1]
Internet-Draft Multicast Service Models July 2016
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. Multicast service models . . . . . . . . . . . . . . . . . . 3
3. Multicast building blocks . . . . . . . . . . . . . . . . . . 4
3.1. Multicast addressing . . . . . . . . . . . . . . . . . . 4
3.2. Host signalling . . . . . . . . . . . . . . . . . . . . . 4
3.3. Multicast snooping . . . . . . . . . . . . . . . . . . . 4
4. ASM service model protocols . . . . . . . . . . . . . . . . . 5
4.1. Protocol Independent Multicast, Dense Mode (PIM-DM) . . . 5
4.2. Protocol Independent Multicast, Sparse Mode (PIM-SM) . . 5
4.2.1. Inter-domain PIM-SM, and MSDP . . . . . . . . . . . . 5
4.3. Bidirectional PIM (BIDIR-PIM) . . . . . . . . . . . . . . 6
4.4. IPv6 PIM-SM with Embedded RP . . . . . . . . . . . . . . 6
5. SSM service model protocols . . . . . . . . . . . . . . . . . 6
5.1. Source Specific Multicast (PIM-SSM) . . . . . . . . . . . 6
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. ASM Deployment . . . . . . . . . . . . . . . . . . . . . 7
6.2. SSM Deployment . . . . . . . . . . . . . . . . . . . . . 7
6.3. Other considerations . . . . . . . . . . . . . . . . . . 8
6.3.1. Scalability, and multicast domains . . . . . . . . . 9
6.3.2. Reliable multicast . . . . . . . . . . . . . . . . . 9
6.3.3. Inter-domain multicast peering . . . . . . . . . . . 9
6.3.4. Layer 2 multicast domains . . . . . . . . . . . . . . 9
6.3.5. Anything else? . . . . . . . . . . . . . . . . . . . 9
7. Use case examples . . . . . . . . . . . . . . . . . . . . . . 10
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
IP Multicast has been deployed in various forms, both within private
networks and on the wider Internet. While a number of service models
have been published individually, and in many cases revised over
time, there is, we believe, no high-level guidance in the form of an
Informational RFC documenting the models, their advantages and
Abrahamsson, et al. Expires January 7, 2017 [Page 2]
Internet-Draft Multicast Service Models July 2016
disadvantages, and their appropriateness to certain scenarios. This
document aims to fill that gap.
This initial version of the document is not complete. There are
other topics that can be included. The aim of this initial version
is to determine whether this work is deemed of value within the IETF
mboned WG.
2. Multicast service models
The general IP multicast service model [RFC1112] is that senders send
to a multicast IP address, receivers express an interest in traffic
sent to a given multicast address, and that routers figure out how to
deliver traffic from the senders to the receivers.
The benefit of IP multicast is that it enables delivery of content
such that any multicast packet sent from a source to a given
multicast group address appears once and only once on any path
between a sender and an interested receiver that has joined that
multicast group. A reserved range of addresses (for either IPv4 or
IPv6) is used for multicast group communication.
Two high-level flavours of this service model have evolved over time.
In Any-Source Multicast (ASM), any number of sources may transmit
multicast packets, and those sources may come and go over the course
of a multicast session without being known a priori. In ASM,
receivers express interest in a given multicast group address. In
Source-Specific Multicast (SSM) the specific source(s) that may send
traffic to the group are known in advance. In SSM, receivers express
interest in a given multicast address and specific source(s).
Senders transmit multicast packets without knowing where receivers
are, or how many there are. Receivers are able to signal to on-link
routers their desire to receive multicast content sent to a given
multicast group, and in the case of SSM from specific sender IP
addresses. They may discover the group (and sender IP) information
in a number of different ways. They may also signal their desire to
no longer receive multicast traffic for a given group (and sender
IP).
Multicast routing protocols are used to establish the multicast
forwarding paths (tree) between a sender and a set of receivers.
Each router would typically maintain multicast forwarding state for a
given group (and potentially sender IP), such that it knows which
interfaces to forward (and where necessary replicate) multicast
packets to.
Abrahamsson, et al. Expires January 7, 2017 [Page 3]
Internet-Draft Multicast Service Models July 2016
Multicast packet forwarding is generally not considered a reliable
service. It is typically unidirectional, but a bidirectional
multicast delivery mechanism also exists.
3. Multicast building blocks
In this section we describe general multicast building blocks that
are applicable to both ASM and SSM deployment.
3.1. Multicast addressing
IANA has reserved specific ranges of IPv4 and IPv6 address space for
multicast addressing.
Guidelines for IPv4 multicast address assignments can be found in
[RFC5771]. IPv4 has no explicit multicast address format; a specific
portion of the overall IPv4 address space is reserved for multicast
use (224.0.0.0/4).
Guidelines for IPv6 multicast address assignments can be found in
[RFC2375] and [RFC3307]. The IPv6 multicast address format is
described in [RFC4291]. An IPv6 multicast group address will lie
within ff00::/8.
3.2. Host signalling
A host wishing to signal interest in receiving (or no longer
receiving) multicast to a given multicast group (and potentially from
a specific sender IP) may do so by sending a packet using one of the
protocols described below on an appropriate interface.
For IPv4, a host may use Internet Group Management Protocol Version 2
(IGMPv2) [RFC2236] to signal interest in a given group. IGMPv3
[RFC3376] has the added capability of specifying interest in
receiving multicast packets from specific sources.
For IPv6, a host may use Multicast Listener Discovery Protocol (MLD)
[RFC2710] to signal interest in a given group. MLDv2 [RFC3810] has
the added capability of specifying interest in receiving multicast
packets from specific sources.
Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].
3.3. Multicast snooping
Is this appropriate in this document? There is discussion in
[RFC4541].
Abrahamsson, et al. Expires January 7, 2017 [Page 4]
Internet-Draft Multicast Service Models July 2016
4. ASM service model protocols
4.1. Protocol Independent Multicast, Dense Mode (PIM-DM)
PIM-DM is detailed in [RFC3973]. It operates by flooding multicast
messages to all routers within the network in which it is configured.
This ensures multicast data packets reach all interested receivers
behind edge routers. Prune messages are used by routers to tell
upstream routers to (temporarily) stop forwarding multicast for
groups for which they have no known receivers.
PIM-DM remains an Experimental protocol since its publication in
2005.
4.2. Protocol Independent Multicast, Sparse Mode (PIM-SM)
The most recent revision of PIM-SM is detailed in [RFC7761]. PIM-SM
is, as the name suggests, well-suited to scenarios where the subnets
with receivers are sparsely distributed throughout the network. PIM-
SM supports any number of senders for a given multicast group, which
do not need to be known in advance, and which may come and go through
the session. PIM-SM does not use a flooding phase, making it more
scalable and efficient than PIM-DM, but this means PIM-SM needs a
mechanism to construct the multicast forwarding tree (and associated
forwarding tables in the routers) without flooding the network.
To achieve this, PIM-SM introduces the concept of a Rendezvous Point
(RP) for a PIM domain. All routers in a PIM-SM domain are then
configured to use specific RP(s). Such configuration may be
performed by a variety of methods, including Anycast-RP [RFC4610].
A sending host's Designated Router encapsulates multicast packets to
the RP, and a receiving host's Designated Router can forward PIM JOIN
messages to the RP, in so doing forming what is known as the
Rendezvous Point Tree (RPT). Optimisation of the tree may then
happen once the receiving host's router is aware of the sender's IP,
and a source-specific JOIN message may be sent towards it, in so
doing forming the Shortest Path Tree (SPT). Unnecessary RPT paths
are removed after the SPT is established.
4.2.1. Inter-domain PIM-SM, and MSDP
PIM-SM can in principle operate over any network in which the
cooperating routers are configured with RPs. But in general, PIM-SM
for a given domain will use an RP configured for that domain. There
is thus a challenge in enabling PIM-SM to work between multiple
domains, i.e. to allow an RP in one domain to learn the existence of
a source in another domain, such that a receiver's router in one
Abrahamsson, et al. Expires January 7, 2017 [Page 5]
Internet-Draft Multicast Service Models July 2016
domain can know to forward a PIM JOIN towards a source's Designated
Router in another domain. The solution to this problem is to use an
inter-RP signalling protocol known as Multicast Source Discovery
Protocol (MSDP). [RFC3618].
Deployment scenarios for MSDP are given in [RFC4611]. MSDP remains
an Experimental protocol since its publication in 2003. MSDP was not
replicated for IPv6.
4.3. Bidirectional PIM (BIDIR-PIM)
BIDIR-PIM is detailed in [RFC5015]. In contrast to PIM-SM, it can
establish bi-directional multicast forwarding trees between multicast
sources and receivers.
Add more...
4.4. IPv6 PIM-SM with Embedded RP
Within a single PIM domain, PIM-SM for IPv6 works largely the same as
it does for IPv4. However, the size of the IPv6 address (128 bits)
allows a different mechanism for multicast routers to determine the
RP for a given multicast group address. Embedded-RP [RFC3956]
specifies a method to embed the unicast RP IP address in an IPv6
multicast group address, allowing routers supporting the protocol to
determine the RP for the group without any prior configuration.
Embedded-RP allows PIM-SM operation across any network in which there
is an end-to-end path of routers supporting the protocol. By
embedding the RP address in this way, multicast for a given group can
operate inter-domain without the need for an explicit source
discovery protocol (i.e. without MSDP for IPv6). It would be
desirable that the RP would be located close to the sender(s) in the
group.
5. SSM service model protocols
5.1. Source Specific Multicast (PIM-SSM)
PIM-SSM is detailed in [RFC4607]. In contrast to PIM-SM, PIM-SSM
benefits from assuming that source(s) are known about in advance,
i.e. the source IP address is known (by some out of band mechanism),
and thus the receiver's router can send a PIM JOIN directly towards
the sender, without needing to use an RP.
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
designated as source-specific multicast (SSM) destination addresses
and are reserved for use by source-specific applications and
Abrahamsson, et al. Expires January 7, 2017 [Page 6]
Internet-Draft Multicast Service Models July 2016
protocols. For IPv6, the address prefix FF3x::/32 is reserved for
source-specific multicast use.
6. Discussion
In this section we discuss the applicability of the ASM and SSM
models described above, and their associated protocols, to a range of
deployment scenarios. The context is framed in a campus / enterprise
environment, but the draft could broaden its scope to other
environments (thoughts?).
6.1. ASM Deployment
PIM-DM remains an Experimental protocol, that appears to be rarely
used in campus or enterprise environments. Open question: what are
the use cases for PIM-DM today?
In campus scenarios, PIM-SM is in common use. The configuration and
management of an RP is not onerous. However, if interworking with
external PIM domains in IPv4 multicast deployments is needed, MSDP is
required to exchange information between domain RPs about sources.
MSDP remains an Experimental protocol, and can be a complex and
fragile protocol to administer and troubleshoot. MSDP is also
specific to IPv4; it was not carried forward to IPv6.
PIM-SM is a general purpose protocol that can handle all use cases.
In particular, it is well-suited to cases where one or more sources
may came and go during a multicast session. For cases where a
single, persistent source is used, PIM-SM has unnecessary complexity.
As stated above, MSDP was not taken forward to IPv6. Instead, IPv6
has Embedded-RP, which allows the RP address for a multicast group to
be embedded in the group address, making RP discovery automatic, if
all routers on the path between a receiver and a sender support the
protocol. Embedded-RP is well-suited for lightweight ad-hoc
deployments. However, it does rely on a single RP for an entire
group. Embedded-RP was run successfully between European and US
academic networks during the 6NET project in 2004/05. Its usage
generally remains constrained to academic networks.
BIDIR-PIM is designed, as the name suggests, for bidirectional use
cases.
6.2. SSM Deployment
As stated in RFC4607, SSM is particularly well-suited to
dissemination-style applications with one or more senders whose
identities are known (by some mechanism) before the application
Abrahamsson, et al. Expires January 7, 2017 [Page 7]
Internet-Draft Multicast Service Models July 2016
begins. PIM-SSM is therefore very well-suited to applications such
as IP TV.
Some benefits of PIM-SSM are presented in RFC 4607:
"Elimination of cross-delivery of traffic when two sources
simultaneously use the same source-specific destination address;
Avoidance of the need for inter-host coordination when choosing
source-specific addresses, as a consequence of the above;
Avoidance of many of the router protocols and algorithms that are
needed to provide the ASM service model."
A significant benefit of SSM is its reduced complexity through
eliminating network-based source discovery. This means no RPs,
shared trees, SPT switchover, PIM registers, MSDP or data-driven
state creation. It is really just a small subset of PIM-SM, plus
IGMPv3. This makes it radically simpler to manage, troubleshoot and
operate.
SSM is considered more secure in that it supports access control,
i.e. you only get packets from the sources you explicitly ask for, as
opposed to ASM where anyone can decide to send traffic to a PIM-SM
group address.
It is often thought that ASM is required for multicast applications
where there are multiple sources. However, RFC4607 also describes
how SSM can be used instead of PIM-SM for multi-party applications:
"SSM can be used to build multi-source applications where all
participants' identities are not known in advance, but the multi-
source "rendezvous" functionality does not occur in the network
layer in this case. Just like in an application that uses unicast
as the underlying transport, this functionality can be implemented
by the application or by an application-layer library."
A disadvantage of SSM is that it requires hosts using SSM and (edge)
routers with SSM receivers to support the new(er) IGMPv3 and MLDv2
protocols. The slow delivery of support in some OSes has meant that
adoption of SSM has also been slower than might have been expected,
or hoped.
6.3. Other considerations
Abrahamsson, et al. Expires January 7, 2017 [Page 8]
Internet-Draft Multicast Service Models July 2016
6.3.1. Scalability, and multicast domains
One of the challenges in wider-scale multicast deployment is its
scalability, if it is expected that multicast-enabled routers are
required to hold state for large numbers of multicast sources/groups.
In practice, the number of groups a given router needs to hold state
for is limited by the propagation of the multicast messages for any
given group, e.g. because only a specific connected set of routers
are multicast-enabled, or because multicast scope borders have been
configured between multicast-enabled routers for access control
purposes. Further, protocol policy/filters are typically used to
limit state, as well as access control.
IPv4 multicast has no explicit indication of scope boundaries within
its multicast address format. The prefix 239.0.0.0/8 is reserved for
private use within a network, as per [RFC2365], and is believed to be
in common usage. Other scopes within this range are defined, e.g.
Organizational Local Scope, but whether this is in common use is
unclear.
In contrast, IPv6 has specific flag bits reserved to indicate the
scope of an address, e.g. link (0x2), site (0x5), organisation (0x8)
or global (0xe), as described in [RFC7346]. Such explicit scoping
makes configuration of scope boundaries a simpler, cleaner process.
6.3.2. Reliable multicast
Do we want to go here, and if so which protocols should we mention?
FLUTE [RFC6726] might be one example.
6.3.3. Inter-domain multicast peering
Interdomain peering best practices are documented in
[I-D.ietf-mboned-interdomain-peering-bcp].
6.3.4. Layer 2 multicast domains
Open question - do we want to look at L2 models, e.g. as might be
applied at an IXP?
6.3.5. Anything else?
Anything else to add here?
Abrahamsson, et al. Expires January 7, 2017 [Page 9]
Internet-Draft Multicast Service Models July 2016
7. Use case examples
Aim to add 2-3 deployment examples here, if deemed useful. Perhaps
one PIM-SM/MSDP/Anycast-RP, one Embedded-RP, one SSM?
8. Conclusions
Do we wish to make a very strong recommendation here for the SSM
service model, and thus for PIM-SSM, even in multi-source
applications?
Is this document Informational or BCP? Currently assumed
Informational.
9. Security Considerations
Do we need general text on multicast security here, or not?
10. IANA Considerations
This document currently makes no request of IANA.
Note to RFC Editor: this section may be removed upon publication as
an RFC.
11. Acknowledgments
TBC if draft progresses...
12. References
12.1. Normative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<http://www.rfc-editor.org/info/rfc1112>.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<http://www.rfc-editor.org/info/rfc2236>.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, DOI 10.17487/RFC2365, July 1998,
<http://www.rfc-editor.org/info/rfc2365>.
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998,
<http://www.rfc-editor.org/info/rfc2375>.
Abrahamsson, et al. Expires January 7, 2017 [Page 10]
Internet-Draft Multicast Service Models July 2016
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999,
<http://www.rfc-editor.org/info/rfc2710>.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
<http://www.rfc-editor.org/info/rfc3307>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<http://www.rfc-editor.org/info/rfc3376>.
[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618,
DOI 10.17487/RFC3618, October 2003,
<http://www.rfc-editor.org/info/rfc3618>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, DOI 10.17487/RFC3956, November 2004,
<http://www.rfc-editor.org/info/rfc3956>.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005, <http://www.rfc-editor.org/info/rfc3973>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<http://www.rfc-editor.org/info/rfc4607>.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610,
DOI 10.17487/RFC4610, August 2006,
<http://www.rfc-editor.org/info/rfc4610>.
Abrahamsson, et al. Expires January 7, 2017 [Page 11]
Internet-Draft Multicast Service Models July 2016
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
DOI 10.17487/RFC5771, March 2010,
<http://www.rfc-editor.org/info/rfc5771>.
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 6726, DOI 10.17487/RFC6726, November 2012,
<http://www.rfc-editor.org/info/rfc6726>.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
DOI 10.17487/RFC7346, August 2014,
<http://www.rfc-editor.org/info/rfc7346>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>.
12.2. Informative References
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<http://www.rfc-editor.org/info/rfc4541>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <http://www.rfc-editor.org/info/rfc4604>.
[RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source
Discovery Protocol (MSDP) Deployment Scenarios", BCP 121,
RFC 4611, DOI 10.17487/RFC4611, August 2006,
<http://www.rfc-editor.org/info/rfc4611>.
Abrahamsson, et al. Expires January 7, 2017 [Page 12]
Internet-Draft Multicast Service Models July 2016
[I-D.ietf-mboned-interdomain-peering-bcp]
Tarapore, P., Sayko, R., Shepherd, G., Eckert, T., and R.
Krishnan, "Use of Multicast Across Inter-Domain Peering
Points", draft-ietf-mboned-interdomain-peering-bcp-03
(work in progress), May 2016.
Authors' Addresses
Mikael Abrahamsson
T-Systems
Stockholm
Sweden
Email: mikael.abrahamsson@t-systems.se
Tim Chown
Jisc
Lumen House, Library Avenue
Harwell Oxford, Didcot OX11 0SG
United Kingdom
Email: tim.chown@jisc.ac.uk
Lenny Giuliano
Juniper Networks, Inc.
2251 Corporate Park Drive
Hemdon, Virginia 20171
United States
Email: lenny@juniper.net
Abrahamsson, et al. Expires January 7, 2017 [Page 13]