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

Versions: 00 01 02                                                      
INTERNET DRAFT                                                   M. Ohta
draft-ohta-static-multicast-00.txt         Tokyo Institute of Technology
                                                            J. Crowcroft
                                               University College London
                                                              March 1998

                            Static Multicast

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 view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

                                 Abstract

   The current IP Multicast model appears to achieve a level of
   simplicity by extending the IP unicast addressing model (historically
   the classful A,B, and C net numbers) from the mask and longest match
   schemes of CIDR, with a new classful address space, class D. The
   routing systems have been also built in a deceptively simple way in
   one of three manners - either broadcast and prune (DVMRP, Dense Mode
   PIM), destination list  based tree computation (MOSPF) or single
   centered trees (current sparse mode PIM and CBT). The multicast
   service creates the illusion of a spectrum that one can "tune in to",
   as an application writer. Due to this view, many have seen the
   multicast pilot service, the Mbone, as a worldwide Ethernet, where
   simple distributed algorithms can be used to allocate "wavelengths"
   and advertise them through "broadcast" on a channel (the session
   directory), associated with a spectrum.

   These three pieces of the picture have tempted people to construct a
   distributed architecture for a number of next level services that
   cannot work at more than a modest scale, since they ignore the basic
   spirit of location independence for senders and receivers of IP
   packets, whether unicast or multicast. The problem is that many of



M. Ohta              Expires on September 20, 1998              [Page 1]


INTERNET DRAFT              Static Multicast                  March 1998


   these services are attempting to group activities at source, when it
   is only at join time that user grouping becomes apparent (if you
   like, multicast usage is a good example of very late binding). These
   services include Address Allocation and Session Creation,
   Advertisement and Discovery.

   This memo proposes approaches to solve some current multicast
   problems rather statically with DNS and URL based approach, and avoid
   the misguided pitfalls of trying to use address allocation to
   implement traffic aggregation for different sources or aggregation of
   multicast route policy control through control of such aggregated
   sources.

   Note that a minor level of aggregation occurs in applications which
   source cumulative layered data (e.g. audio/video/game data - ref
   vic/rat/rlc) - this memo is orthogonal to such an approach, which in
   any case ony results in a small constant factor reduction in state.

   A lot of the IP multicast additional pieces of baggage are associated
   with the multimedia conferencing on Mbone - however, the commercial
   internet use of multicast includes many other applications - for
   these, SDR may not be the best directory model.

1. Introduction

   Multicast and related applications have traditionally been developed
   in Routing and Transport areas. Naturally, designers have tried to
   solve many problems using techniques familiar to those working in the
   routing and transport areas, that is, with flooding or multicast.

   Of course, global flooding or multicast do not scale very well, which
   means that scalable solutions that make use of these techniques only
   are often impossible in the world wide Internet.

   An attempt to reduce the scalability requirement to localize
   multicast and flooding area through TTL or administrative scoping
   (intra-site, intra-provider multicast etc.) works only in a small
   scale experiment like Mbone. In the real Internet, senders and
   receivers of multicast communication, in general, may be using
   different providers and are distributed beyond AS boundaries.

   As a result, there was a hope that address aggregation and unicast
   area topology report aggregation can solve the multicast scalability
   problems in the same way that they have bailed out the unicast
   Internet from problems with limitation of router memory and the
   capacity needed for route update reports:

      a) Unicast addresses refer to a location, however. Multicast



M. Ohta              Expires on September 20, 1998              [Page 2]


INTERNET DRAFT              Static Multicast                  March 1998


      addresses are logical addresses, and refer to sets of members who
      may be anywhere, and may be sent to by sources which are also in
      more than one of many places. This means that for unrelated
      multicast group (and we anticipate that, in general, we can expect
      relationship between groups only when the groups belongs to a
      single application and that there is far more group that is
      unrelated than there is group that is related), there is no
      meaningful allocation at session creation time of a mask/prefix
      style multicast address, either for destination group, or sources.

      b) To control the amount of state and routing control messages,
      the Internet has divided the routing systems into autonomous
      systems/regions, which can run their own routing, and need only
      report summarized information at the edge to another region. This
      serves two purposes in the Unicast world:

         1/ Inter-domain routing protocols can be deployed that are
         different in different areas (this may be applied recursively).

         2/ Summarization can be applied at "min-cut" points in the
         topology, and reachability information only needs to be
         exported/imported across borders.

      Note that, autonomous system boundaries are merely for operational
      purpose of easy policy description.  The boundary does not
      contribute to protocol issues to reduce the amount of routing
      information, which is accomplished with multi-layered OSPF without
      BGP.

   With multicast, while one could define inter-working boundaries and
   functions as the IDMR WG has, the principle goal of scaling the
   reports at a border cannot be achieved in a location independent
   manner (in the sense that without moving all the receivers to a
   particular region, there is no aggregation feasible).

   As a result of this confusion, intra-domain multicast protocols,
   which are expected to operate within a single AS have been developed
   that scale poorly, even though there was no known inter domain
   multicast protocol which solves the scalability problem.

   It has been shown [MANOLO] that aggregation of multicast routing
   table entries, the number of which is a major scalability problem for
   IP multicast, is, in general, impossible.

   The impossibility proof assumes nothing about QoS.  That is,
   multicast QoS Flow state can be aggregated as good/bad as multicast
   best effort communication. RSVP may be extended to aggregate RSVP
   requests of strongly interrelated flows, for example, for streams



M. Ohta              Expires on September 20, 1998              [Page 3]


INTERNET DRAFT              Static Multicast                  March 1998


   with layered encoding, which may or may not share a single multicast
   address, latter case of which may result in a small constant factor
   of routing table entry reduction.

   There may be a counter argument that a broadcast/prune in region (==
   big ether) and spare in other region for clumpy cast can overcome the
   problem. However, forwarding for "spare in other region" needs a
   routing table entry of its own. Moreover, even in the region,
   "broadcast/prune" scales worse than the theoretical lower bound of
   PIM-SM/CBT [MANOLO].

   Thus, it is now necessary to thoroughly reconsider the architecture
   of multicast, Given a theoretical lower bound of multicast routing
   table entries, now is the time to find a multicast algorithm to
   achieve that lower bound. It is also meaningful to make the multicast
   architecture independent of unicast address hierarchy.

   Fortunately, some problems can easily be solved for many common cases
   using techniques available in other areas without scalability
   problems.

   Since the legacy multicast architecture was constructed carefully
   assuming routing table aggregation possible, it is necessary to
   change some of it to deploy new techniques.  To solve hard
   scalability problems, it is necessary to recognize that all the
   details of all the protocols are tightly interrelated.

   The multicast problems identified to be better solved in internet or
   application area in this memo are:

      Multicast Address Allocation

         There was a proposal to allocate multicast address dynamically
         along the unicast address hierarchy.  Such an allocation policy
         was expected to enhance the possibility of aggregation.
         However, as shown in the next section, it is impossible to
         aggregate multicast routing table. Then, while it is still
         possible to aggregate multicast address allocation, it is not
         meaningful.

         However, it is meaningful to allocate multicast addresses
         statically through the DNS.

      Multicast Core/RP Location

         CBT and PIM-SM were developed as intra-domain multicast
         protocols designed to be independent of the underlying unicast
         routing protocols.  Naturally, they achieve the lower bound of



M. Ohta              Expires on September 20, 1998              [Page 4]


INTERNET DRAFT              Static Multicast                  March 1998


         spatial routing table size complexity.  However, CBT and PIM-SM
         are not totally independent of unicast routing architecture,
         since they depends on flooding within an AS to locate the core
         or rendez-vous point. While this scales a little better than
         static assignment, it is still fairly bad.  On the other hand,
         it is straight forward to use DNS to map from DNS multicast
         name to multicast address, core and RP.  This solution may not
         be an option when dynamic multicast address assignment was a
         MUST and DNS dynamic update was not possible. However, this is
         now rectified since DNS update is being implemented now.

      Multicast Session Announcement

         The announcement of multicast sessions can be performed over a
         special multicast channel. But the approach does not scale if
         the number of multicast channels increases. Of course, it is
         possible to introduce hierarchy of multicast session
         announcement channels.  The real world complex structure makes
         the relationships between session announcement a complex
         network.  Then, users join a session directory hierarchy by
         joining a group for some level, following the hierarchy, or
         following short-cut or following links, changing between
         several multicast groups to reach the final destination
         multicast for the session they seek.  But as is proven,
         multicast costs routing table entries and associated protocol
         processing power of routers if a data of the multicast flows
         over the routers.  So, it is desirable to constrain the number
         of multicast channels to be as small as possible.

         If, instead, we use WWW as EPG (Electric Program Guide) and
         embed SDP or SMIL information in RTP URLs, it can be used as
         multicast session announcement with arbitrary complex structure
         of hierarchy, short-cut or links with some caching, and we can
         use search techniques on this static data more easily.

   Of course, neither DNS nor WWW scale automatically: they must
   continue to scale anyway and a lot of effort was already and will
   continue to be paid to make them better scale, more dynamic and more
   secure and their servers are becoming more capable (caching etc).
   DNS will be used for unicast name to address lookup forever and WWW
   will be the preferred way to retrieve information.

2. Meaningless Aggregation of Multicast Addresses

   It is, in general, impossible to aggregate multicast routing table
   entries.

   The minimum amount of state in each multicast router must be



M. Ohta              Expires on September 20, 1998              [Page 5]


INTERNET DRAFT              Static Multicast                  March 1998


   proportional to the number of multicast data flows which are running
   over it.

   The locations of receivers are different, multicast application by
   multicast application. Multicast forwarding must be performed over a
   tree of receivers. The sources are different too.  Thus, the tree is
   different multicast by multicast.

   It is possible to aggregate multicast address allocation by making
   multicast location dependent with, say, a root domain.  Then, it is
   possible to aggregate routing table entries to the root domain. For
   some type of central set of agencies (traditional broadcast TV/Radio)
   it might be possible to site their feeds at the same places in the
   Internet. But this is antithetical to the arbitrary growth allowed by
   random siting/evolution of content providers today, even in the Web.
   Sheer numbers preclude building unicast pipes from each source to a
   central set of sites.

   However, it is still impossible to aggregate routing table entries to
   the receivers. The distribution pattern of receivers is unrelated to
   the location of the root domain. That is, a separate routing table
   entry is necessary for each multicast application.

   A group of multicast receivers sharing a root domain may still have
   weak relationships in that most of them do not have any member in
   domains far from the root domain. Then, it is possible to share a
   default routing table entry, not to forward anything.  But, such an
   entry is meaningless, because there is no data packet that will be
   forwarded for the entry and we still need unaggregated routing table
   entries for each multicast running over multicast routers.

   Alternatively, it is possible to assign multicast addresses
   aggregated according to the statically or runtime detected
   distribution pattern of the receiver hosts, areas or domains.
   However, even with 32 receiver hosts, areas or domains, we need 32
   bits for the aggregation prefix of the multicast addresses, which is
   too many for IPv4. Even IPv6 address space does not help a lot (96
   receivers is not a great step forward!).  Moreover, as the multicast
   membership changes dynamically, the multicast address itself must
   change dynamically.

   That is, according to the current model of the Internet multicast, it
   is impossible to aggregate multicast routing table entries.

   It is meaningless to try to aggregate multicast address assignment.

   Still, it, of course, is meaningful and necessary to hierarchically
   delegate multicast address allocation.



M. Ohta              Expires on September 20, 1998              [Page 6]


INTERNET DRAFT              Static Multicast                  March 1998


3. The Difficulty of (Multicast) Address Assignment

   Compared to the administrative effort for unicast address assignment
   by IANA, Internic, RIPE, APNIC and all the country NICs and
   development of the policy they used, it is trivially easy to develop
   a DHCP protocol. The difficulty with DHCP was in the fact that the
   clients can not be reached by its IP address.  It is even more
   trivial to develop a DHCP-like dynamic multicast address assignment
   protocol for clients unicast addresses which are already established.
   It could be as simple as a new option field of DHCP.

   However, such a use of DHCP is meaningless, unless an administrator
   of the DHCP server has been delegated a block of unicast addresses
   and establishes a policy on how to assign them to clients.
   Similarly, we can argue that the DHCP-like mechanism for multicast is
   not a good solution.

   Basically, multicast address assignment is not a protocol issue.

4. Recycling the Unicast Policy, Mechanism and Established Address
   Assignment for Multicast Policy, Mechanism and Address Assignment

   If rather static allocation of multicast address  is acceptable, it
   is possible to reuse the policy, mechanism, address assignment and
   protocol of unicast address assignment for multicast addresses..

   For example, if we decide to use 225.0.0.0/8 for the static
   allocation, it is trivial to delegate the authority of multicast
   address 225.1.2.3 to an administrator of 3.2.1.in-addr.arpa, the
   administrator of 1.2.3.0/24.

   We can simply define that the multicast DNS name should be looked up
   as:

      3.2.192.225.in-addr.arpa.     CNAME mcast.3.2.192.in-addr.arpa.

      mcast.3.2.192.in-addr.arpa.   PTR     bbc.com.

      bbc.com.                      A       225.192.2.3

   Then, if we construct applications that check the reverse mapping,
   unauthorized use of multicast addresses will be automatically
   rejected, which is what we are doing today with unicast addresses.

   Note that the administrator of 3.2.192.in-addr.arpa is not the final
   person to be delegated the address but can further delegate the
   authority of mcast.3.2.192.in-addr.arpa.  to someone else.




M. Ohta              Expires on September 20, 1998              [Page 7]


INTERNET DRAFT              Static Multicast                  March 1998


   It should also be noted that, while the delegation uses the existing
   policy, mechanism, assignment and protocol, it does not mean that the
   multicast address must be used within the unicast routing domain of
   the unicast address block.

   Just as MX servers or name servers can be located anywhere in the
   Internet regardless of the location of the hosts under the DNS domain
   they are serving, multicast channels can be used anywhere in the
   world.

   The assingment policy automatically assure global uniqueness.  But,
   it is still possible to have multicast addresses with local scopes,
   as long as they share globally unique well known DNS names, which is
   what we are using for intra-subnet multicast with IANA assigned well
   known names [IANA].

5. Core/RP location

   The location of core of CBT or rendez-vous point of PIM-SM through
   DNS is straight forward as:

      bbc.com.   A     255.192.2.3
                 RVP   london-station.bbc.com.

   or

      bbc.com.   A     255.192.2.3
                 CORE  london-station.bbc.com.

   Again, just as MX servers or name servers can be located anywhere in
   the Internet regardless of the location of the hosts under the DNS
   domain they are serving, core or rendez-vous points can be located
   anywhere in the world.

   CORE and RVP RRs have exactly the same syntax as PTR RR.  Their query
   type values are <to be assigned by IANA>.  While the current CBT nor
   PIM-SM does not allow a single multicast group has multiple cores or
   rendez-vous points, future extension may. Thus, at the DNS level, a
   single node may have multiple CORE or RVP RRs. That is, the following
   DNS node is a valid node:

      bbc.com.   A     255.192.2.3
                 RVP   london-station.bbc.com.
                 RVP   wales-station.bbc.com.

6. Session Announcement

   The proposal is essentially to use a URL of RTP combined with SDP



M. Ohta              Expires on September 20, 1998              [Page 8]


INTERNET DRAFT              Static Multicast                  March 1998


   like:

      rtp://london-station.bbc.com/?t=2873397496+2873404696&
      m=audio+3456+RTP/AVP+0&m=video+2232+RTP/AVP+31

   The URL contains all the necessary information to establish a
   session, including the domain name (or multicast address), port
   number(s), RTP payload type and optional QoS requirement.

   Then, users surfing over WWW can actively search or randomly
   encounter some multicast or unicast RTP URL.

   If the user clicks the label of the URL, the user will be queried
   whether he want to receive (should be default for multicast) or send
   data or both (should be default for unicast).  He will also queried
   the source or destination of the data with appropriate default (his
   TV at the living room) and the multicast session begins, if
   necessary, with RSVP.

7. References

   [MANOLO] http://web.jet.es/sola/inet98.html

   [IANA]

   [CBT]

   [PIM]

8. Security Considerations

   (to be written)

9. Authors' Addresses

   Masataka Ohta
   Computer Center
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku
   Tokyo 152, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3415
   EMail: mohta@necom830.hpcl.titech.ac.jp

   Jon Crowcroft
   Dept. of Computer Science
   University College London



M. Ohta              Expires on September 20, 1998              [Page 9]


INTERNET DRAFT              Static Multicast                  March 1998


   London WC1E 6BT, UK

   EMail: j.crowcroft@cs.ucl.ac.uk
















































M. Ohta              Expires on September 20, 1998             [Page 10]