Network Working Group Internet 2
Internet-Draft September 1997
Internet Protocol Multicast Problem Statement
<draft-bradner-multicast-problem-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document outlines the evolving requirements for Multicast
functionality within next generation Internet Protocol networks, and
is the product of an ad hoc Internet2 working group meeting held
August 25-27, 1997 hosted by Cisco Systems, Inc. This document is
offered to the IP community for its consideration and comments.
1.0 Introduction
Multicast technology is important to data networks such as Internet2
because it can be used to conserve resources in the network such as
circuit bandwidth and router resources. By reducing the amount of
duplicate traffic in the network, it makes applications that operate
in one-to-many and many-to-many configuration operate in a more
efficient manner. This in turn allows the developers of these
applications to add more functionality without significantly
impacting the network. Many applications including distance learning
and videoconferencing are natural users of multicast technology.
Others like scientific data distribution, global resource
announcement, and distributed simulation are emerging applications
that will be hindered without native multicast support.
In some cases, using multicast technology in place of multiple
unicast streams improves the quality of existing applications. In
the case of videoconferencing, this may result in a higher frame rate
or improved conference control. In other cases, such applications as
I2 [Page 1]
Internet-Draft Multicast Problem Statement September 1997
distributed virtual reality or multi-user scientific visualization
are impossible to build without multicast due to the shear volume of
data that needs to be transmitted.
Experience with technologies like "Internet broadcasting" (RealAudio)
and "information-push" (Pointcast) technologies has shown that if a
dependable, ubiquitous multicast service does not exist, application
builders will come up with their own sub-optimal unicast-based
distribution methods. In order to circumvent inefficient use of
network resources by their users, Internet2 designers hope that
native multicast support will provide the basis for efficient
application design.
1.1 Requirement for a 2nd generation multicast backbone
Internet2 represents an opportunity to deploy a second generation
multicast backbone. In our view, the current multicast experience
with the MBONE has demonstrated the limitations of this
implementation of multicast technology. Interoperability with the
existing MBONE infrastructure need not be a requirement for this
deployment. At this point, there is no reason to believe that
existing IGMP-based multicast clients will not be supportable.
1.1.1 Existing MBONE technology experience
A second generation multicast backbone must avoid several problems
that have characterized the MBONE and have inhibited its deployment
within the Internet. The historical channel rate limitation has
restricted multimedia sessions to a largely unacceptable production
quality. The historical overall rate constraint and the lack of a
coherent scoping mechanism have limited the number and diversity of
simultaneous sessions. Much of the current MBONE is built upon
uncoordinated multicast tunnels that are inconsistent with the
underlying unicast topology. Finally, interprovider multicast
traffic exchange across multiple access media at exchange points has
proven both difficult and inefficient.
1) The management model for the current multicast "service" is "the
MBONE staff" which is a collection of researchers and engineers
that maintain the experiment. The new multicast backbone can't
have a single staff. That is, management must be distributed (much
like the unicast Internet is today).
2) The existing routing technology uses a flat routing architecture
as one might deploy in a small AS. This can not scale to a
generally useful level. The current MBONE does not easily provide
a way to introduce new multicast routing protocols.
3) Multicast policy and access-control are non-existent. Route
filtering and packet filtering are the only means today to achieve
crude forms of policy routing.
4) The current MBONE is free access and generaltes no specific
I2 [Page 2]
Internet-Draft Multicast Problem Statement September 1997
revenue. Therefore, you can't get people to manage it with any
urgency.
2.0 Next generation multicast backbone goals
Some of the high performance applications envisioned by the designers
of Internet2 would benefit from the availability of a ubiquitous IP
multicast service. Examples of these applications include
distribution of software updates, propagation of realtime scientific
data, efficient network news delivery, distance learning classes, and
video conferences (local, regional, national, international).
The diversity of these applications requires that differential QoS
support be inherent in the multicast services providing for requested
characteristics of delay, reliability, and bandwidth as outlined in
[I2 QoS doc]. Multicast distribution must be controllable according
to the specifications outlined in the [I2 policy routing doc].
The multicast services must be robust. The presence of multicast
traffic on a network must not disproportionately degrade unicast
traffic.
1) The multicast service must provide 1-to-many communication, where
many may reach into the tens of thousands. In addition, the
multicast service must be able to provide low delay many-to-many
communication for groups consisting of hundreds of hosts. And
the multicast service must be able to provide best-effort service
for many-to-many communication for groups consisting of thousands
of hosts.
2) IP Multicast functionality must be supported on all future media
(Sonet rings, cable, etc).
2.1 Control
It is desirable to have robust admission control at both the core and
edges of a multicast tree. There are a number of distinct components
to control that are described below.
2.1.1 Administrative Scoping
It is vital that network and system administrators be able to control
who can use multicasting services in a network. Administrators must
be able to put specific limitations on the total amount of multicast
traffic present on their networks, control which LAN segments can
receive a specific multicast group, and control which users can send
into each multicast group. Implementing such controls could require
wide spread distribution of control information. A network of
cooperating multicast policy servers would be one way to enable the
distribution of the control information required to implement these
types of access controls.
I2 [Page 3]
Internet-Draft Multicast Problem Statement September 1997
2.1.2 Content Privacy
There are instances where the content of a particular multicast group
must be accessible only a specific set of users. Administrative
scoping as described above is not sufficient to ensure this level of
access control since anyone on a LAN with one or more legitimate
users would be able to receive the multicast group. Encryption of
the datastream in the multicast group would be a way to ensure the
privacy of the group but the implementation of any such function is
the responsibility of both the application on the end system and its
user and specifically not of the multicast infrastructure itself.
Encrpytion for privacy is a strong requirement and must be ubiquitous
in all applications. It must not be assumed that the problem is
solved by the network layer.
2.1.3 Control privacy
Privacy of multicast control traffic in the application control
stream is a requirement. For example, this may be implemented
through encryption of control traffic.
2.1.4 Multicast traffic only upon request
In the large scale multicast operations that we expect to develop in
the future Internet, global flooding of all multicast groups to all
possible LAN segments is not a reasonable policy. Traffic for a
specific multicast group should only be forwarded to a network
infrastructure and onto a LAN segment in response to a specific and
authorized request from a end system on that LAN to receive or join
that group or as a result of a specific managerial configuration
decision. Specifically client attachments must use an explicit
joining type protocol
2.2 Routing
The IETF's Inter-Domain Multicast Routing (IDMR) working group has
produced several multicast routing protocols, including Core Based
Trees [CBT] and Protocol Independent Multicasting [PIMARCH]. In
addition, the IDMR WG has formalized the specification of the
Distance Vector Multicast Routing Protocol [DVMRP]. Various
specifications for protocol interoperation have also been produced
(see, for example, [THALER96] and [PIMMBR]).
2.2.1 Recommendations
Since multicast will be a ubiquitous service, the next generation
Internet will require both Multicast Interior Gateway Protocols
(MIGPs) and Multicast Exterior Gateway Protocols (MEGPs) to field
multicast services. Some of these recommendations can be expressed
in terms of the ongoing IETF standards process as follows:
a. We encourage the IETF to converge on a single Internet standard
for intradomain multicast routing.
I2 [Page 4]
Internet-Draft Multicast Problem Statement September 1997
b. We encourage the IETF to expedite work on a single inter-domain
multicast routing protocol.
c. We encourage the IETF to expedite work on a multi-protocol policy
based routing protocol. A protocol that allows for both unicast
and multicast Network Layer Reachability Information is a near
term requirement.
2.3 Management
Multicast management tools must expose the underlying group
forwarding topology, group membership, compliance with requested
transmission properties, and source reachability. To enable the
integration of standard network management techniques with the
operation of multicast network services, additional SNMP MIBs are
required so that typical network management stations can plainly
display the state of the multicast service.
The development of multicast troubleshooting tools that are analogous
to common unicast tools is required to further this integration. The
multicast equivalents of traceroute and ping should support
troubleshooting of both member-to-source and source-to-member modes.
Management tools should be aware of multicast policy and should be
able to interact with any multicast policy control mechanisms.
Multicast forwarding agents should be able to generate traps that
alert management systems to changes in group membership, forwarding
tree changes, and high resource utilization.
2.4 Implementation requirements
Since multicast deployment is necessary for scaling of the Internet,
vendor implementations must not hinder - and ideally should
facilitate - this deployment. In particular, the low-level multicast
management tools provided by manufacturers should be designed so that
they can be readily incorporated into the routine operations of ISPs,
exchange points, and campus networks and their NOCs. Administrative
tools should, insofar as possible, be extensions of their unicast
counterparts. It is also important that the multicast software
implementation in routers and switches be on a par with the unicast
code; i.e., the proportion of resources consumed by servicing the
multicast environment should be commensurate with the proportion of
multicast traffic.
3.0 Security Considerations
It is quite easy to have multicast distributions be perceived as a
denial of service attack on local networks. Secure mechanisms are
required to ensure that network operators have adequate capabilities
to manage multicast environments including being able to control who
I2 [Page 5]
Internet-Draft Multicast Problem Statement September 1997
can send into a multicast group and who can subscribe to receive a
group. (See section 2.1.) Additionally implementations should honor
source-specific IGMP prunes so that a denial of service attack can be
pruned all the way to the first hop network segment.
4.0 Participants
Scott Bradner <sob@harvard.edu>
Chris Buja <cbuja@cisco.com>
Steve Corbato <corbato@cac.washington.edu>
Bruce Davie <bdavie@cisco.com>
Ken Hays <hays@scri.fsu.edu>
Ron Hutchins <ron@gatech.edu>
Paul Hyder <hyder@ucar.edu>
Jim Leighton <jfl@es.net>
David Meyer <meyer@antc.uoregon.edu>
John Meylor <jmeylor@cisco.com>
Becca Nitzan <nitzan@es.net>
Achutha Rao <acrao@cisco.com>
Steve Shultz <shultz@nsipo.nasa.gov>
Ben Teitelbaum <ben@internet2.edu>
Kevin Thompson <kthomp@mci.net>
Alex Tweedly <agt@cisco.com>
Steven Wallace <ssw@indiana.edu>
David Wasley <david.wasley@ucop.edu>
Steve Wolff <swolff@cisco.com>
Paul J. Zawada <zawada@ncsa.uiuc.edu>
5.0 Author's Address
editor
Scott Bradner
Harvard University
1350 Mass Ave.
Cambridge MA 02138
+1 617 495 3864
sob@harvard.edu
6.0 References
[CBT] A. Ballardie, et. al., "Core Based Trees (CBT)
Multicast -- Protocol Specification --",
draft-ietf-idmr-cbt-spec-06.txt, September, 1996.
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing
Protocol", draft-ietf-idmr-dvmrp-v3-03, September,
1996.
[PIMARCH] D. Estrin, et. al., "Protocol Independent Multicast
Sparse Mode (PIM-SM): Motivation and Architecture",
I2 [Page 6]
Internet-Draft Multicast Problem Statement September 1997
draft-ietf-idmr-pim-arch-04.ps , October, 1996.
[PIMMBR] D. Estrin, et. al., "PIM Multicast Border Router
(PMBR) specification for connecting PIM-SM domains
to a DVMRP Backbone", draft-ietf-idmr-PIMBR-spec-01.ps,
September, 1996.
[THALER96] D. Thaler, "Interoperability Rules for Multicast
Routing Protocols", draft-thaler-interop-00.ps,
November, 1996.
[I2 QoS doc] Internet 2, "Internet Protocol Quality of Service Problem Statement", draft-internet2-qos-problem-00.txt, Sept. 1997
I2 [Page 7]