idnits 2.17.1 draft-ietf-svrloc-service-mcast-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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'SLP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRV' ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Service Location Working Group Erik Guttman 2 Internet Draft Sun Microsystems, Inc. 3 Expires in six months 5 Service Specific Multicast Address Assignment 6 for use with the Service Location Protocol 7 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as 18 ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet- 22 Drafts Shadow Directories on ftp.is.co.za (Africa), 23 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 24 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 One feature of the Service Location Protocol is that Services may 29 be assigned a Service Specific Multicast address to aid in service 30 discovery. Use of this address for service discovery will not 31 burden systems which do not advertise the service type. Two open 32 questions are answered in the following proposal: How are the 33 multicast addresses to be assigned? How are these multicast 34 addresses known by SLP Service and User Agents? 36 1.0 Introduction 38 SLP User Agents can request information about services by 39 multicasting requests to service specific multicast addresses. 40 Only Service Agents which have service information for these 41 services will receive the request. Other Service Agents will 42 never receieve them, as the multicast request will be filtered out 43 by the link layer. 45 There are two unanswered questions which must be answered in order 46 to successfully make use of Service Specific Multicast addresses. 47 The first is how will new multicast addresses be assigned. The 48 second is how will new assignments be known and by UAs and SAs. 50 =0C 52 2.0 String Hashing of Service Types to Multicast Addresses 54 A range of (for example) 1024 contiguous multicast addresses will 55 be requested from IANA for use with service location. The service 56 specific multicast address is the string hash of the service's 57 "service type" string identifier. For example "nfs" would be 58 hashed, then the last 10 significant bits of the hash would be 59 used to determine the multicast address within the range. 61 Service Specific Multicast addresses do not need to be unique in 62 order to server their purpose. If spurious requests arrive at an 63 SA due to hashing collisions, the SA can always discard the 64 request, as it would do anyway if it received a request on the 65 Service Location General Multicast address. What will occur is 66 that SAs representing very few services will not receive nearly as 67 many spurious requests as if all requests were made to the Service 68 Location General Multicast address. 70 This solves the assignment problem. All service types, whether 71 they are standardized or not, can be hashed into a particular 72 multicast address. Discovery of service types will now 73 effectively also discover Service Specific Multicast addresses. 74 Finally, the effort of standardizing new service types will be 75 disassociated from that of Multicast Address assignements. This 76 will reduce the necessary interaction with the IANA required to 77 standardize new service types. It will also make it possible for 78 nonstandard service types to make use of Service Specific 79 Multicast addresses. This simplification changes [SRV] and [SLP]=20 80 which specify that these addresses are directly assigned by IANA. =20 82 The string hash function is attributed to Chris Torek:=20 84 unsigned long SLPhash(const char *pc) { 85 unsigned long h =3D 0; 86 for (; *pc; pc++) { 87 h *=3D 33; 88 h +=3D *pc; 89 } 90 return (0x2FF & h); /* round to a range of 0-1023 */ 91 } 93 The string which should be passed into this function is the 94 service type string, as a null terminated ASCII string. The 95 service type will always be expressable as a string even if the 96 service URL is in another character set. That is because the 97 grammar definition of a URL is such that all allowable characters 98 in a URL are in a very restricted set of characters; all of which 99 fall within the ASCII range. 101 =0C 103 3.0 Security Considerations 105 There are no security ramifications to mapping service type 106 strings to multicast addresses. 108 4.0 Internationalization Considerations 110 The service type string must be expressed in subset of the ASCII 111 character set. This is a restriction posed by the URL encoding 112 standard [URL]. Unfortunately, this limits the representation of 113 service type names, which will make it difficult to name services 114 in languages which use characters outside of this restricted set. 116 5.0 Acknowledgments 118 This internet draft spells out a proposal made by Thomas Narten 119 last year to provide a simple and powerful solution to both 120 multicast address assignment and disseminating knowledge of those 121 assignments. 123 6.0 References 125 [SLP] J. Veizades, E. Guttman, C. Perkins & S. Kaplan, 126 "Service Location Protocol", Work in progress, 127 January 1997. 129 [SRV] E. Guttman, "The service: URL Scheme", Work in 130 progress, November 1996. 132 [URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uni- 133 form Resource Locators (URL)", RFC 1738. December 134 1994. 136 7.0 Author's Address 138 Erik Guttman 140 Sun Microsystems, Inc. 141 Gaisbergstr. 6 142 D-69115 Heidelberg 143 Germany 145 Phone: +49 6221 601649 146 Fax : +49 6221 161019 147 email: Erik.Guttman@eng.sun.com 149 This memo expires on August 12, 1997