One document matched: draft-ohta-static-multicast-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 20:50:48 |