One document matched: draft-ohta-static-multicast-01.txt
Differences from draft-ohta-static-multicast-00.txt
INTERNET DRAFT M. Ohta
draft-ohta-static-multicast-01.txt Tokyo Institute of Technology
J. Crowcroft
University College London
October 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 April 30, 1999 [Page 1]
INTERNET DRAFT Static Multicast October 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 only 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 April 30, 1999 [Page 2]
INTERNET DRAFT Static Multicast October 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 April 30, 1999 [Page 3]
INTERNET DRAFT Static Multicast October 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].
The impossibility of the multicast routing entry aggregation is
applicable to the entire Internet or to a small part, such as a
single subnet, of it. Still, in a small part of the Internet
containing are 4 parties (host, subnet, subdomain, etc.), all the
possible multicast forwarding pattern is 16 that, in a sense,
multicast routing table aggregation is possible, if multicast
addresses can be assigned according to the distribution pattern of
the receivers. So, there may still be some misunderstanding that in
multi-access link layers, such as Ethernet or ATM, where link local
address can be assigned dynamically, multicast forwarding state may
be aggregated. However, at the boundary, full routing table look-up
based on the IP addresses is necessary. Worse, if the part contains
16 parties, the possible pattern of receivers is 65536 that there
virtually is no aggregation possible. MPLS hype is, as usual, as
good/bad as using some multi-access link and does not help here.
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
M. Ohta Expires on April 30, 1999 [Page 4]
INTERNET DRAFT Static Multicast October 1998
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 a class D multicast routing table using simple mask
and longest match type approaches. This, while it is still
possible to aggregate multicast address allocations, it is not
meaningful.
There is a misunderstanding that multicast addresses are scarce
resource that must be assigned dynamically. But, first of all,
dynamic assignment does not mean efficient assignment.
Secondly, as a multicast routing table cannot be aggregated,
the limitation on routing table size in many of today's routers
is such that we simply will run out of memory on a router
before we run out of addresses or even use a significant piece
of the class D address space: Considering the current global
unicast routing table size, 2^16 global multicast addresses are
more than enough.
Given these arguments, we can see that from performance
grounds, 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
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. However, this 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
M. Ohta Expires on April 30, 1999 [Page 5]
INTERNET DRAFT Static Multicast October 1998
the relationships between session announcement a complex
problem. In such a system, users would 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 shown later, multicasting costs routing table entries and
associated protocol processing power in the routers if
multicast data flows over the routers. Hence 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 declaration with an arbitrary complex
structure including hierarchy, short-cut or links, 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 has already and will
continue to be paid to make them better scale, more dynamically and
more securely. and their servers are also becoming more capable
(caching etc). DNS will be used for unicast name to address lookup
for the foreseeable future, as WWW will be the preferred way to
retrieve information.
2. Meaningless Aggregation of Multicast Addresses
It is, in general, impossible to aggregate Internet standard
multicast routing table entries.
The minimum amount of state in each multicast router must be
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 from each source (or from core/RP) to the receiver set for each
and every application. 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.
M. Ohta Expires on April 30, 1999 [Page 6]
INTERNET DRAFT Static Multicast October 1998
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 that 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.
In other words, if we stay in line with the current model of the
Internet standard multicast, it is impossible to aggregate multicast
routing table entries. It is meaningless to try to aggregate
multicast address assignment.
It is, of course, meaningful and necessary to delegate multicast
address allocation, hierarchically
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. In the absence of this
bootstrap problem, it is trivial to develop a DHCP-like dynamic
multicast address assignment protocol for clients, whose unicast
addresses 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
M. Ohta Expires on April 30, 1999 [Page 7]
INTERNET DRAFT Static Multicast October 1998
and establishes a policy on how to assign them to clients. We argue
that the DHCP-like mechanism for multicast is a misdirected 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
Additionally 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.
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 assures global uniqueness.
However, it is still possible to have multicast addresses with local
scopes, as long as they share globally unique well known DNS names,
M. Ohta Expires on April 30, 1999 [Page 8]
INTERNET DRAFT Static Multicast October 1998
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>. Neither the current CBT
nor PIM-SM allow a single multicast group that has multiple cores or
rendez-vous points, though 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
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 on the anchor of a URL, the user will be queried
M. Ohta Expires on April 30, 1999 [Page 9]
INTERNET DRAFT Static Multicast October 1998
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. Policy Considerations
Some people wrongly believe that the separation of multicast routing
into the classical intra and inter domain functions is necessary for
multicast policy control.
Multicat policy is controlled by controlling forwarding direction of
multicast control or data packets, which is controlled by the unicast
routing table.
If separate control of multicast and unicast policy is desired, what
is necessary is to instantiate two sets of unicast routing tables,
one used for normal unicast routing and the other to be consulted by
multicast protocols.
While there may be intra and inter domain unicast routing and inter
domain multicast forwarding policy, we don't need a novel protocol to
disseminate policies in some multicast specific way for inter and
intra domain multicast policy routing. FOrwarding is forwarding.
8. References
[MANOLO] Manolo Sola, Masataka Ohta, Toshinori Maeno, "Scalability of
Internet Multicast Protocols", Proceedings of INET'98,
http://www.isoc.org/inet98/proceedings/6d/6d_3.htm, July 1998.
[IANA] For now, http://www.iana.org/
[CBT] RFC 2189 Core Based Trees (CBT version 2) Multicast Routing. A.
Ballardie. September 1997.
[PIM] RFC 2117 Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler,
S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June
1997.
9. Security Considerations
For routers to merge multiple JOIN requests, which may contain
different (forged or wrong) Cores/RPs of the same group, and to
forward the JOIN to the true Core/RP, the routers must be able to
look up Core/RP from group address by themselves with some (weak or
M. Ohta Expires on April 30, 1999 [Page 10]
INTERNET DRAFT Static Multicast October 1998
strong) security.
The Core/RP information can not be flooded in advance for obvious
scalability problem that the look up must be on demand.
Because of this, e-mail, WWW or SDR can not be used to look up
Core/RP and DNS is the easiest way.
10. 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
London WC1E 6BT, UK
EMail: j.crowcroft@cs.ucl.ac.uk
M. Ohta Expires on April 30, 1999 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 20:42:53 |