Service Location Protocol

Il Service Location Protocol (SLP, srvloc) è un protocollo di rilevamento dei servizi che consente a computer e altri dispositivi di trovare servizi in una rete locale senza previa configurazione. SLP è stato progettato per scalare da piccole reti non gestite a reti aziendali di grandi dimensioni. È stato definito in RFC 2608 e RFC 3224 come documento di tracciabilità degli standard.

SLP viene utilizzato dai dispositivi per annunciare i servizi su una rete locale. Ciascun servizio deve avere un URL utilizzato per individuare il servizio. Inoltre può avere un numero illimitato di coppie nome/valore, denominate attributi. Ciascun dispositivo deve sempre trovarsi in uno o più ambiti. Gli ambiti sono semplici stringhe e vengono utilizzati per raggruppare i servizi, paragonabili alle vicinanze della rete in altri sistemi. Un dispositivo non può vedere i servizi che si trovano in ambiti diversi.

L'URL di una stampante potrebbe essere simile a:

service:printer:lpr://myprinter/myqueue

Questo URL descrive una coda denominata "myqueue" su una stampante con il nome host "myprinter". Il protocollo utilizzato dalla stampante è LPR. Si noti che la stampante utilizza uno schema URL speciale "servizio:". Gli URL "servizio:" non sono obbligatori: è possibile utilizzare qualsiasi schema di URL, ma consentono di cercare tutti i servizi dello stesso tipo (es. tutte le stampanti) indipendentemente dal protocollo utilizzato. I primi tre componenti del tipo di URL "service:" ("service:printer:lpr") sono anche chiamati service type. I primi due componenti ("servizio:stampante") sono chiamati tipo di servizio astratto. In un URL non "servizio:" il nome dello schema è il tipo di servizio.

Gli attributi della stampante potrebbero assomigliare a:

(printer-name=Hugo),
(printer-natural-language-configured=en-us),
(printer-location=In my home office),
(printer-document-format-supported=application/postscript),
(printer-color-supported=false),
(printer-compression-supported=deflate, gzip)

L'esempio utilizza la sintassi standard per gli attributi in SLP, sono state aggiunte solo nuove righe per migliorare la leggibilità.

La definizione di un "servizio": URL e gli attributi consentiti per l'URL sono specificati da un modello di servizio, una descrizione formalizzata della sintassi dell'URL e gli attributi. I modelli di servizio sono definiti in RFC 2609 .

SLP consente a diversi tipi di query di individuare i servizi e ottenere informazioni su di essi:

• Può cercare tutti i servizi con lo stesso tipo di servizio o tipo di servizio astratto
• La query può essere combinata con una query per attributi, utilizzando il linguaggio di query di LDAP.
• Dato il suo URL, è possibile richiedere gli attributi di un servizio. In SLP standard gli attributi non vengono restituiti nel risultato della query e devono essere recuperati separatamente. L'estensione elenco attributi (RFC 3059) risolve questo problema.
• È possibile ottenere un elenco di tutti i tipi di servizio
• È possibile richiedere un elenco di tutti gli ambiti esistenti.

SLP ha tre ruoli diversi per i dispositivi. Un dispositivo può anche avere due o tutti e tre i ruoli contemporaneamente.

• Gli User Agent (UA) sono dispositivi che cercano servizi
• I Service Agents (SA) sono dispositivi che annunciano uno o più servizi
• I Directory Agents (DA) sono dispositivi che memorizzano nella cache le informazioni sui servizi. Vengono utilizzati in reti più grandi per ridurre la quantità di traffico e consentire la scalabilità di SLP. L'esistenza di DA in una rete è facoltativa, ma se è presente un DA, UA e SA devono utilizzarlo invece di comunicare direttamente.

Oggi la maggior parte delle implementazioni sono demoni che possono agire sia come UA che come SA. Di solito possono essere configurati per diventare anche DA.

SLP è un protocollo orientato ai pacchetti. La maggior parte dei pacchetti viene trasmessa utilizzando UDP, ma TCP può essere utilizzato anche per la trasmissione di pacchetti più lunghi. A causa della potenziale inaffidabilità di UDP, SLP ripete tutti i multicast più volte a intervalli crescenti fino a quando non viene ricevuta una risposta. Tutti i dispositivi devono ascoltare sulla porta 427 i pacchetti UDP, SA e DA dovrebbero anche ascoltare TCP sulla stessa porta. Il multicasting è ampiamente utilizzato da SLP, in particolare dai dispositivi che si uniscono a una rete e devono trovare altri dispositivi.

Il funzionamento di SLP varia notevolmente, a seconda che un Directory Agent (DA) sia nella rete o meno. Quando un client si unisce per la prima volta a una rete, esegue il multicast di una query per i DA sulla rete. Se nessun DA risponde, presumerà che sia in una rete senza DA. È anche possibile aggiungere DA in un secondo momento, poiché trasmettono in multicast un pacchetto "heartbeat" in un intervallo predefinito che verrà ricevuto da tutti gli altri dispositivi. Quando una SA scopre un DA, è necessario registrare tutti i servizi presso il DA. Quando un servizio scompare, la SA dovrebbe avvisare il DA e annullare la registrazione.

Per inviare una query in una rete senza un DA, l'UA invia un pacchetto UDP multicast che contiene la query. Tutte le SA che contengono corrispondenze invieranno una risposta UDP all'UA. Se la risposta è troppo grande per adattarsi a un singolo pacchetto UDP, il pacchetto verrà contrassegnato come "overflow" e l'UA è libero di inviare la query direttamente alla SA utilizzando TCP, che può trasmettere pacchetti di qualsiasi dimensione.

Per inviare una query in una rete con un DA, l'UA invierà il pacchetto di query al DA utilizzando UDP o TCP. Poiché ogni SA deve registrare tutti i servizi con la DA, la DA è in grado di soddisfare completamente la richiesta e invia semplicemente il risultato all'UA.

SLP contiene un meccanismo di sicurezza basato sulla crittografia a chiave pubblica che consente la firma degli annunci di servizio. In pratica si usa raramente:

• Le chiavi pubbliche di ogni provider di servizi devono essere installate su ogni UA. Questo requisito vanifica lo scopo originale di SLP, essendo in grado di individuare i servizi senza una configurazione preliminare.
• Proteggere solo i servizi non basta. Gli URL dei servizi contengono nomi host o indirizzi IP e in una rete locale è quasi impossibile prevenire lo spoofing IP o DNS. Pertanto, garantire solo l'autenticità dell'URL non è sufficiente se qualsiasi dispositivo può rispondere all'indirizzo.
• Poiché gli indirizzi possono essere falsificati, l'autenticità del dispositivo deve essere comunque provata a un livello diverso, ad esempio nel protocollo dell'applicazione (ad esempio con SSL) o nel livello del pacchetto (IPsec). Farlo in aggiunta in SLP non fornisce molta sicurezza aggiuntiva.

• SLP è spesso utilizzato per localizzare le stampanti ed è supportato da sistemi di stampa come CUPS.
• SLP si trova spesso nelle stampanti abilitate alla LAN, in modo che siano rilevabili immediatamente. Alcuni driver di stampa client possono utilizzarlo per il rilevamento della stampante.
• ACN, un protocollo in fase di sviluppo per il controllo dell'intrattenimento, utilizza SLP per trovare diversi dispositivi come dimmer e luci intelligenti.
• Il classico Mac OS e Mac OS X fino alla versione 10.1 utilizzavano SLP per individuare condivisioni file e altri servizi. Tuttavia, le funzionalità introdotte con Mac OS X (dalla versione 10.2 in poi) utilizzano Zeroconf.
• I client Netware Core Protocol (NCP) in un ambiente IP puro utilizzano SLP per individuare i server Novell NetWare e Novell Open Enterprise Server (OES).
• SUSE Linux supporta SLP per una varietà di servizi dalla versione 9.1.
• Sun Microsystems supporta SLPv1 e SLPv2, comprese le funzionalità SA, UA e DA.^[1]
• La Distributed Management Task Force ha standardizzato il rilevamento dei servizi WBEM tramite SLP.
• La Storage Networking Industry Association ha imposto l'uso di SLP per il rilevamento dei servizi nella specifica dell'iniziativa di gestione dello storage .

• Bonjour
• Protocollo di configurazione host dinamico
• OSGi
• Plug and Play universale
• Rete a configurazione zero

• Il modulo LiveTribe SLP/OSGi, su livetribe.org (archiviato dall'url originale il 26 maggio 2015).
• Progetto del protocollo di localizzazione del servizio, su srvloc.sourceforge.net.
• Miglioramenti del protocollo di posizione del servizio Archiviato il 22 aprile 2016 in Internet Archive.
• OpenSLP, su openslp.org.
• jSLP - Un'implementazione SLP Java pura., su jslp.sourceforge.net.
• SBLIM CIM Client per Java : include un'implementazione SLP conforme a RFC 2614 in Java.
• Un confronto tra i protocolli di rilevamento dei servizi e l'implementazione del protocollo di localizzazione dei servizi, su citeseer.ist.psu.edu.
• https://web.archive.org/web/20050312060250/http://www.ietf.org/html.charters/svrloc-charter.html -- Gruppo di lavoro IETF SRVLOC, che ha creato lo standard SLP
• Rilevamento WBEM tramite SLP da DMTF
• Modello WBEM SLP di DMTF
• Automatizza la gestione dei clienti con il Service Location Protocol, un articolo di developerWorks di M. Tim Jones