INTERNET DRAFT Manolo Sola (1)
draft-sola-ocbt-static-multicast-00.txt Masataka Ohta (2)
(1) Waseda University
(2) Tokyo Institute of Technology
August 1998
Modifications to OCBT for 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
OCBT is a CBT-based multicast protocol that allows multiple cores for
a multicast group. The goal in OCBT is to set up and mantain a
unique bidirectional multicast tree connecting members with cores,
and also cores among themselves. This tree is used to deliver
multicast traffic to members of the multicast group. To accomplish
that objective, members, non-member senders, routers with members and
cores must know the IP unicast address of cores and the IP multicast
address for the multicast group. This is a key issue in tree-based
multicast protocols using centers, cores, or rendevous points, and
their main source of lack of scalability. In OCBT this key issue is
open.
In this Internet-Draft we proposed to use Static Multicast as an
scalable solution to this problem.
M.Sola and M.Ohta Expires on February 1999 [Page 1]
INTERNET DRAFT Modifications to OCBT for Static Multicast August 1998
1. Introduction
When an administrator desires to run a multicast group, first of all,
an IP multicast address must be obtained from an IP multicast address
delegation authority.
The proposed delegation mechanism for multicast addresses in [static-
multicast] is summarized in the following paragraph:
An administrator who has been delegated the set of 2^8 addresses
{X.Y.Z.0 to X.Y.Z.255} is also delegated the set of 2^4 multicast
addresses {M.X.Y.Z, with M=224,...,239} as:
224.X.Y.Z CNAME mcast0.Z.Y.X.in-addr.arpa.
. . .
. . .
. . .
239.X.Y.Z CNAME mcast15.Z.Y.X.in-addr.arpa.
, and that administrator becomes an IP multicast address
delegation authority, so he or she can further subdelegate any
subset of the 2^4 multicast addresses in the same way he or she
can further subdelegate any subset of the 2^8 unicast addresses.
As some of the multicast address space has already been assigned,
some addresses can not be used. To ensure that these addresses will
never be used for static multicast, or to reserve some multicast
address space for other purposes, the set of valid values for M may
be reduced.
2. Summary of the new feautures introduced in this draft
In [OCBT] it is assumed "that some mechanism for distributing core
information is universally available and that each router can find
the address and level of any core". In this draft this open issue is
solved by means of Static Multicast.
Also, this draft proposes that the Core placement and migration
strategy must be decided by the administrator of the multicast group,
and that a router must be configured by its administrator in order to
behave as a Core.
3. Core behaviour
3.1 Number of Cores and distribution of Core's information
The administrator of a multicast group G must decide how many Cores
will exist for G and where they will be located and, following the
M.Sola and M.Ohta Expires on February 1999 [Page 2]
INTERNET DRAFT Modifications to OCBT for Static Multicast August 1998
rules in [static-multicast], DNS must be used to make worldwide
available the information about Cores and the IP multicast address
for the multicast group.
For OCBT, a new RR should be defined in DNS. We illustrate it with an
example:
bbc.com OCBT 0 england.bbc.com
OCBT 1 scotland.bbc.com
OCBT 2 wales.bbc.com
OCBT 3 north-ireland.bbc.com
The DNS packet format is identical to that of MX [RFC1035], and the
QTYPE value for an OCBT query is <to be assigned by IANA>. The
integer numbers indicate the Core's level.
The administrator of the multicast group must contact the
administrator of a router that will behave as a Core so that the
router can be configured properly. A router must know whether it is
an OCBT Core by means of a configuration paramenter at the router
which must be set by the administrator of that router.
When a router configured as a Core for multicast group G starts to
run, it must query DNS to get the list of Cores for G.
4. Router and host behaviour
If a router or host needs to know about Cores for a multicast group,
the router or host must query DNS to obtain that information, unless
it has queried DNS before and the TTL of the information retrieved
has not expired yet.
5. Security Considerations
The security considerations of this method of distributing Core
information is equivalent to the security of DNS.
References
[static-multicast] M. Ohta, J. Crowcroft, "Static Multicast," Work in
progress, ftp://ftp.ietf.org/internet-drafts/draft-ohta-static-
multicast-00.txt
[OCBT] C. Shields, J. J. Garcia-Luna-Aceves, "The Ordered Core Based
Tree Protocol," in Proc. of IEEE Infocom97, Kobe, Japan, April 1997.
Author's Address
M.Sola and M.Ohta Expires on February 1999 [Page 3]
INTERNET DRAFT Modifications to OCBT for Static Multicast August 1998
Manolo Sola
Waseda University
School of Science and Engineering
Department of Information and Computer Science
3-4-1 Okubo, Shinjuku
Tokyo 169-8555, JAPAN
Phone: +81-3-5734-3299
Fax: +81-3-5734-3415
EMail: sola@jet.es
Masataka Ohta
Tokyo Institute of Technology
Computer Center
12-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
M.Sola and M.Ohta Expires on February 1999 [Page 4]