Papers /

Guttman-IETF 1999






Warhammer 40k








Guttman-IETF 1999

RFC 2608 & 2609: Service Location Protocol, v2

Guttman, Perkins, Veizades, Day

zeroconf mdns slp service discovery multicast network configuration

  author={E. Guttman and C. Perkins and J. Veizades and M. Day},
  title={Service Location Protocol, Version 2},
  series={Request for Comments},
  howpublished={{RFC} 2608 (Proposed Standard)},
  organization={Internet Engineering Task Force},
  note={Updated by RFC 3224},

  author={E. Guttman and C. Perkins and J. Kempf},
  title={Service Templates and Service: Schemes},
  series={Request for Comments},
  howpublished={{RFC} 2609 (Proposed Standard)},
  organization={Internet Engineering Task Force},

Goal: Little to no static configuration, for enhanced portability

Designed for enterprise networks

  • May not scale to wide-area networks or the Internet
    • (hundreds of thousands of clients, tens of thousands of services)
  • Also requires enterprise level of administrative control
    • Allows security, multicast routing, and physical location control

Requests are directly multicast to services

  • Matching services unicast a reply back

In larger networks, directories cache advertisements

  • Services register advertisements with directories
  • Clients unicast requests to known directories

Directories are discovered by multicasting for them

  • Directory agents also infrequently broadcast their own identity

Clients are given scopes

SLP Messages

  • Service Type Request/Reply: Requests list of all service types on the network
  • Attribute Request/Reply: Request for attributes of a given type or even particular service
  • Service Deregister/Update: Request to remove or change service advertisement
  • SA Advertisement: Used to query services of their scopes

Service URLs have the form:

  • "service:"<srvtype>"://"<addrspec>
    • e.g., service:t
    • srvtype is the concrete service type
    • addrspec is hostname or IP address, optional port number
  • May also have the form
    • "service:"<abstract-type>":"<concrete-type>
    • "service:"<abstract-type>
  • e.g., service:printer
  • Matches both of:
  • But only the latter would match
    • service:printer:http
  • A naming authority can be specialized, making the names distinct:
    • and service:x.two
    • and service:abstract.two:y

Attributes are defined by Service Templates



  • Client contacts directory it gets from DHCP
  • Client contacts pre-configured directory
  • Client multicasts for directories
    • Exponential backoff on looking for directories
  • Client directly multicasts services, services unicast back

Each particular type of service lookup is associated with a scope

Clients that receive a truncated message may open a TCP connection to the directory or service with the response identifier to get details

Requests back off exponentially

String comparisons case-insensitive * wildcards permitted within strings

Not intended to find all matches, intended to find enough to be useful

Requests have the service type and predicate

  • Predicates defined as in LDAPv3, are optional
    • Attribute queries/values must match in type
    • (x=3) matches (x=1,2,3) because it is one of the values for x
    • (!(Y=0)) matches (y=0,1) because y can be non-zero

Information from directories may of course be stale

RFC 2609 tries to elaborate and standardize conventions for the service type URLs

  • Seems to move attributes to the end of the URL
  • Defines a simple typing scheme or frame system
    • Concrete service types inherit attributes from abstract service types
    • Attributes may have a type: String, integer, boolean, opaque, keyword (has no value)
    • Attributes may have default values
    • Attributes may be restricted to a specific set of values
    • Except for booleans and keywords, attributes may optionally be allowed to have multiple values (may not remove individual values)
    • Attributes may be optional
    • Attributes may be marked as not to be translated
    • Attributes may be marked as essentially required for any productive matching

URI examples from 2609:




Template examples from 2609:

  Name of submitter: "Erik Guttman" <>
  Language of service template: en
  Security Considerations:
    There is no authentication of the Transducer output.  Thus,
    the Thermometer output could easily be spoofed.

  Template Text:
  -------------------------template begins here-----------------------


    The Thermometer is a Net-Transducer capable of reading temperature.
    The data is read by opening a TCP connection to one of the ports
    in the service URL and reading an ASCII string until an NULL
    character is encountered.  The client may continue reading data at
    no faster than the sample-rate, or close the connection.

    url-path     = "ports=" ports-list
    port-list    = port / port "," ports
    port         = 1*DIGIT
                   ; See the Service URL <port> production rule.
                   ; These are the ports connections can be made on.

  # The location where the Thermometer is located.

  operator=string O
  # The operator to contact to have the Thermometer serviced.

  --------------------------template ends here------------------------
Recent Changes (All) | Edit SideBar Page last modified on October 25, 2010, at 06:30 PM Edit Page | Page History
Powered by PmWiki