RFC 2608 & 2609: Service Location Protocol, v2
Guttman, Perkins, Veizades, Day
zeroconf mdns slp service discovery multicast network configuration
@misc{guttman:ietf-1999a,
author={E. Guttman and C. Perkins and J. Veizades and M. Day},
title={Service Location Protocol, Version 2},
series={Request for Comments},
number={2608},
howpublished={{RFC} 2608 (Proposed Standard)},
publisher={IETF},
organization={Internet Engineering Task Force},
year={1999},
month={June},
note={Updated by RFC 3224},
url={\url{http://www.ietf.org/rfc/rfc2608.txt}},
}
@misc{guttman:ietf-1999b,
author={E. Guttman and C. Perkins and J. Kempf},
title={Service Templates and Service: Schemes},
series={Request for Comments},
number={2609},
howpublished={{RFC} 2609 (Proposed Standard)},
publisher={IETF},
organization={Internet Engineering Task Force},
year={1999},
month={June},
url={\url{http://www.ietf.org/rfc/rfc2609.txt}},
}
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:tftp://bad.glad.org:8080
- 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
- A naming authority can be specialized, making the names distinct:
- service:x.one and service:x.two
- service:abstract.one:y and service:abstract.two:y
Attributes are defined by Service Templates
UDP
Precedence
- 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:
service:device-drivers:ftp://x3.bean.org/drivers/diskdrivers.drv;
driver=scsi;platform=sys3.2-rs3000
service:device-drivers:tftp://x2.bean.org/vol3/disk/drivers.drv;
driver=scsi;platform=sys3.2-rs3000
service:device-drivers:http://www.bean.org/drivers/drivpak.drv;
driver=scsi;platform=sys3.2-rs3000
Template examples from 2609:
Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com>
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-----------------------
template-type=service:Net-Transducer:Thermometer
template-version=0.0
template-description=
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.
template-url-syntax=
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.
location-description=string
# The location where the Thermometer is located.
operator=string O
# The operator to contact to have the Thermometer serviced.
--------------------------template ends here------------------------