[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                         Internet 2
Internet-Draft                                            September 1997

             Internet Protocol Multicast Problem Statement

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).

   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

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

   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
   Scott Bradner
   Harvard University
   1350 Mass Ave.
   Cambridge MA 02138

   +1 617 495 3864

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,

   [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]