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