Service Location Working Group Erik Guttman Internet Draft Sun Microsystems, Inc. Expires in six months Service Specific Multicast Address Assignment for use with the Service Location Protocol 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract One feature of the Service Location Protocol is that Services may be assigned a Service Specific Multicast address to aid in service discovery. Use of this address for service discovery will not burden systems which do not advertise the service type. Two open questions are answered in the following proposal: How are the multicast addresses to be assigned? How are these multicast addresses known by SLP Service and User Agents? 1.0 Introduction SLP User Agents can request information about services by multicasting requests to service specific multicast addresses. Only Service Agents which have service information for these services will receive the request. Other Service Agents will never receieve them, as the multicast request will be filtered out by the link layer. There are two unanswered questions which must be answered in order to successfully make use of Service Specific Multicast addresses. The first is how will new multicast addresses be assigned. The second is how will new assignments be known and by UAs and SAs. Guttman Page 1 =0C Internet Draft Multicast Address Assignment 12 February 1997 2.0 String Hashing of Service Types to Multicast Addresses A range of (for example) 1024 contiguous multicast addresses will be requested from IANA for use with service location. The service specific multicast address is the string hash of the service's "service type" string identifier. For example "nfs" would be hashed, then the last 10 significant bits of the hash would be used to determine the multicast address within the range. Service Specific Multicast addresses do not need to be unique in order to server their purpose. If spurious requests arrive at an SA due to hashing collisions, the SA can always discard the request, as it would do anyway if it received a request on the Service Location General Multicast address. What will occur is that SAs representing very few services will not receive nearly as many spurious requests as if all requests were made to the Service Location General Multicast address. This solves the assignment problem. All service types, whether they are standardized or not, can be hashed into a particular multicast address. Discovery of service types will now effectively also discover Service Specific Multicast addresses. Finally, the effort of standardizing new service types will be disassociated from that of Multicast Address assignements. This will reduce the necessary interaction with the IANA required to standardize new service types. It will also make it possible for nonstandard service types to make use of Service Specific Multicast addresses. This simplification changes [SRV] and [SLP]=20 which specify that these addresses are directly assigned by IANA. =20 The string hash function is attributed to Chris Torek:=20 unsigned long SLPhash(const char *pc) { unsigned long h =3D 0; for (; *pc; pc++) { h *=3D 33; h +=3D *pc; } return (0x2FF & h); /* round to a range of 0-1023 */ } The string which should be passed into this function is the service type string, as a null terminated ASCII string. The service type will always be expressable as a string even if the service URL is in another character set. That is because the grammar definition of a URL is such that all allowable characters in a URL are in a very restricted set of characters; all of which fall within the ASCII range. Guttman Page 2 =0C Internet Draft Multicast Address Assignment 12 February 1997 3.0 Security Considerations There are no security ramifications to mapping service type strings to multicast addresses. 4.0 Internationalization Considerations The service type string must be expressed in subset of the ASCII character set. This is a restriction posed by the URL encoding standard [URL]. Unfortunately, this limits the representation of service type names, which will make it difficult to name services in languages which use characters outside of this restricted set. 5.0 Acknowledgments This internet draft spells out a proposal made by Thomas Narten last year to provide a simple and powerful solution to both multicast address assignment and disseminating knowledge of those assignments. 6.0 References [SLP] J. Veizades, E. Guttman, C. Perkins & S. Kaplan, "Service Location Protocol", Work in progress, January 1997. [SRV] E. Guttman, "The service: URL Scheme", Work in progress, November 1996. [URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uni- form Resource Locators (URL)", RFC 1738. December 1994. 7.0 Author's Address Erik Guttman Sun Microsystems, Inc. Gaisbergstr. 6 D-69115 Heidelberg Germany Phone: +49 6221 601649 Fax : +49 6221 161019 email: Erik.Guttman@eng.sun.com This memo expires on August 12, 1997 Guttman Page 3