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

Versions: 00                                                            
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]