Service Location Protocol
updated by
Extracted elements (30)
SLP is explicitly scoped to enterprise networks rather than the global Internet; dynamic discovery of services across the global Internet was deferred to a subsequent protocol document. The intent is shared services within a campus or organization.
The predicate grammar deliberately omits a logical negation operator because SLP has no semantics for returning 'everything except' what matches a criterion in a distributed, incomplete service namespace.
Three distinct operating modes (no DA, DA without scopes, DA with scopes) are defined so that small LANs require zero administration, mid-size networks need only a DA, and large campus networks can partition services into scopes. Each mode requires progressively more administrative effort.
URL technology from the World Wide Web was deliberately reused for service locators so that existing client and server code could be leveraged and browsers could dynamically formulate service requests with context-dependent resolution.
When a reply is too large for a UDP datagram, the SA or DA returns an abbreviated response at the site MTU size with the Overflow bit set; the UA must then reissue the identical request over TCP to obtain the full response.
When multicast is unavailable, SAs SHOULD and DAs MUST listen for broadcast Service Location messages on port 427. Multi-subnet broadcast environments require statically or DHCP-configured DA addresses since dynamic discovery via broadcast is not feasible across subnets.
A Directory Agent MUST decline to register a service with an unsupported scope and return SCOPE_NOT_SUPPORTED; an unscoped DA MUST NOT reject registrations based on scope and MUST accept all Service Registrations.
Applications using SLP MUST be prepared for service information that is stale or incomplete; if returned information does not allow connection to the desired service, the Service Request and/or Attribute Request may be resubmitted.
If a service registration includes authentication blocks that the DA can validate, the DA MUST validate any subsequent service deregistrations (and attribute registrations) to prevent unauthorized entities from invalidating registered services.
If a Service Registration is larger than the site path MTU, the Service Agent MUST use a connection-oriented protocol (TCP) rather than UDP to register with the DA.
Service Agents MUST listen on the Service Location General Multicast Address in addition to all service-specific multicast addresses for the service types they advertise.
Service Agents MUST NOT respond to multicast requests they cannot satisfy; only Service Agents that can fulfill the User Agent's request are permitted to reply.
Service Agents MUST register with unscoped DAs even when specifically configured to use scoped DAs, because unscoped DAs hold all available service information and User Agents may query them.
Service registration in a protected scope MUST include both a URL Authentication block and an Attribute Authentication block; the SA MUST set both the 'U' and 'A' header bits, and the DA MUST verify authentication before registering.
The 'rsvd' bits in the message header MUST be zero; the Dialect field MUST be set to 0 for compatibility with future versions of the Service Location Protocol.
A retransmission/convergence algorithm is used for multicast discovery: the UA resends each request with a previous-responders list, and agents on the list do not reply. The cycle repeats until no new responses arrive, signaling enumeration is complete.
Scopes are administratively assigned logical groupings of services. Scoped DAs only accept and respond to requests matching their scope; unscoped DAs accept all registrations and respond to all requests, making them a catch-all at the cost of scaling.
Service Requests embed a predicate using a prefix-notation boolean grammar of the form <srvtype>[.<na>]/<scope>/<where>/. The where-clause supports AND (&) and OR (|) conjunctions over attribute comparisons and keyword tests; logical negation is absent.
Service-Specific Multicast Addresses are derived by hashing the ASCII-encoded Service Type string using a modified Torek hash (h = h*33 + byte, masked to 0x3FF), yielding a 0-1023 offset added to an IANA-assigned base range of 1024 contiguous multicast addresses.
SLP defines three agent roles: User Agent (UA) discovers services, Service Agent (SA) advertises services on behalf of one or more services, and Directory Agent (DA) centralizes registrations for efficient access. Only one DA is permitted per host.
The 'service:' URL scheme is used by SLP to specify service locations. Service Types are named by appending a scheme after 'service:' (e.g., service:lpr://host:port/queue). Well-known Service Types are registered with IANA as RFC templates.
Transaction IDs (XIDs) are created from a random initial seed and incremented by one per new request. Retransmitted datagrams reuse the same XID so that DAs and SAs can return a cached reply on duplicate requests, avoiding double-processing.
IANA is to assign a base range of 1024 contiguous multicast addresses for Service-Specific Discovery Addresses. Service-specific multicast addresses are derived by adding the SLPhash value (0-1023) of the ASCII-encoded Service Type string to this base address.
All SLP entities configured for protected scopes SHOULD implement 'md5WithRSAEncryption' (BSD value 1) and associate it with the scope's private key. User Agents MAY use the URL Authentication Block in Service Replies to verify a SA is authorized to offer the advertised service.
Authentication blocks include NTP timestamps to prevent replay attacks: both registrations and deregistrations must be timestamped so that a captured deregistration cannot later nullify a valid registration, and a captured registration cannot nullify a valid deregistration.
A URL Entry consists of Lifetime (2 bytes, seconds), Length of URL (2 bytes, must be < 32768), URL (variable), and an optional URL Authentication Block present when the 'U' header flag is set.
An Authentication Block contains a 64-bit NTP Timestamp, a 2-byte Block Structure Descriptor (BSD; value 1 = Object-Identifier), a 2-byte Length, and a Structured Authenticator encoding the algorithm OID and digital signature.
The Service Registration message carries the SLP header (Function=SrvReg=3), a URL-Entry, a 2-byte length-prefixed attribute list string, and an optional Attribute Authentication Block (present only when the 'A' bit is set).
The Service Request message carries the SLP header (Function=SrvReq=1), a 2-byte length-prefixed Previous Responders Address Spec string, and a 2-byte length-prefixed predicate string of the form <srvtype>[.<na>]/<scope>/<where>/.
The SLP general message header is 8 bytes: Version (1), Function (1), Length (2), a flags byte containing O/M/U/A/F bits and reserved bits, Dialect (1), Language Code (2), Character Encoding (2), and XID (2). All SLP messages share this header.