idnits 2.17.1 draft-sola-ocbt-static-multicast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1035' is mentioned on line 107, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'OCBT' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Manolo Sola (1) 3 draft-sola-ocbt-static-multicast-00.txt Masataka Ohta (2) 5 (1) Waseda University 6 (2) Tokyo Institute of Technology 8 August 1998 10 Modifications to OCBT for Static Multicast 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 OCBT is a CBT-based multicast protocol that allows multiple cores for 33 a multicast group. The goal in OCBT is to set up and mantain a 34 unique bidirectional multicast tree connecting members with cores, 35 and also cores among themselves. This tree is used to deliver 36 multicast traffic to members of the multicast group. To accomplish 37 that objective, members, non-member senders, routers with members and 38 cores must know the IP unicast address of cores and the IP multicast 39 address for the multicast group. This is a key issue in tree-based 40 multicast protocols using centers, cores, or rendevous points, and 41 their main source of lack of scalability. In OCBT this key issue is 42 open. 44 In this Internet-Draft we proposed to use Static Multicast as an 45 scalable solution to this problem. 47 1. Introduction 49 When an administrator desires to run a multicast group, first of all, 50 an IP multicast address must be obtained from an IP multicast address 51 delegation authority. 53 The proposed delegation mechanism for multicast addresses in [static- 54 multicast] is summarized in the following paragraph: 56 An administrator who has been delegated the set of 2^8 addresses 57 {X.Y.Z.0 to X.Y.Z.255} is also delegated the set of 2^4 multicast 58 addresses {M.X.Y.Z, with M=224,...,239} as: 60 224.X.Y.Z CNAME mcast0.Z.Y.X.in-addr.arpa. 61 . . . 62 . . . 63 . . . 64 239.X.Y.Z CNAME mcast15.Z.Y.X.in-addr.arpa. 66 , and that administrator becomes an IP multicast address 67 delegation authority, so he or she can further subdelegate any 68 subset of the 2^4 multicast addresses in the same way he or she 69 can further subdelegate any subset of the 2^8 unicast addresses. 71 As some of the multicast address space has already been assigned, 72 some addresses can not be used. To ensure that these addresses will 73 never be used for static multicast, or to reserve some multicast 74 address space for other purposes, the set of valid values for M may 75 be reduced. 77 2. Summary of the new feautures introduced in this draft 79 In [OCBT] it is assumed "that some mechanism for distributing core 80 information is universally available and that each router can find 81 the address and level of any core". In this draft this open issue is 82 solved by means of Static Multicast. 84 Also, this draft proposes that the Core placement and migration 85 strategy must be decided by the administrator of the multicast group, 86 and that a router must be configured by its administrator in order to 87 behave as a Core. 89 3. Core behaviour 91 3.1 Number of Cores and distribution of Core's information 93 The administrator of a multicast group G must decide how many Cores 94 will exist for G and where they will be located and, following the 95 rules in [static-multicast], DNS must be used to make worldwide 96 available the information about Cores and the IP multicast address 97 for the multicast group. 99 For OCBT, a new RR should be defined in DNS. We illustrate it with an 100 example: 102 bbc.com OCBT 0 england.bbc.com 103 OCBT 1 scotland.bbc.com 104 OCBT 2 wales.bbc.com 105 OCBT 3 north-ireland.bbc.com 107 The DNS packet format is identical to that of MX [RFC1035], and the 108 QTYPE value for an OCBT query is . The 109 integer numbers indicate the Core's level. 111 The administrator of the multicast group must contact the 112 administrator of a router that will behave as a Core so that the 113 router can be configured properly. A router must know whether it is 114 an OCBT Core by means of a configuration paramenter at the router 115 which must be set by the administrator of that router. 117 When a router configured as a Core for multicast group G starts to 118 run, it must query DNS to get the list of Cores for G. 120 4. Router and host behaviour 122 If a router or host needs to know about Cores for a multicast group, 123 the router or host must query DNS to obtain that information, unless 124 it has queried DNS before and the TTL of the information retrieved 125 has not expired yet. 127 5. Security Considerations 129 The security considerations of this method of distributing Core 130 information is equivalent to the security of DNS. 132 References 134 [static-multicast] M. Ohta, J. Crowcroft, "Static Multicast," Work in 135 progress, ftp://ftp.ietf.org/internet-drafts/draft-ohta-static- 136 multicast-00.txt 138 [OCBT] C. Shields, J. J. Garcia-Luna-Aceves, "The Ordered Core Based 139 Tree Protocol," in Proc. of IEEE Infocom97, Kobe, Japan, April 1997. 141 Author's Address 142 Manolo Sola 143 Waseda University 144 School of Science and Engineering 145 Department of Information and Computer Science 146 3-4-1 Okubo, Shinjuku 147 Tokyo 169-8555, JAPAN 149 Phone: +81-3-5734-3299 150 Fax: +81-3-5734-3415 151 EMail: sola@jet.es 153 Masataka Ohta 154 Tokyo Institute of Technology 155 Computer Center 156 12-12-1, O-okayama, Meguro-ku 157 Tokyo 152, JAPAN 159 Phone: +81-3-5734-3299 160 Fax: +81-3-5734-3415 161 EMail: mohta@necom830.hpcl.titech.ac.jp