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 . 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]