The goal of a networking system is to use services that are shared on the network. This might include printers, scanners, backups, mail servers, web services, file servers, and instant messaging. Normal IP networking practice is that you need to know the name (or IP address) of a service in order to use it. Automatic service location (or service discovery) is an important tool to ensuring that shared network resources can be found and used without requiring a significant amount of configuration work.
It is worth noting that service location is not a new idea - many systems already have some form of service location. However many of them suffer from serious design flaws, including excessive use of network bandwidth, and using broadcast (which means that service location cannot be scaled to larger networks).
Service Location Protocol is an IETF protocol that provides automatic client configuration for applications and advertisement for network services. Activity continues, although the official IETF working group has concluded.
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. | ||
| --RFC 2608: | ||
Service Location Protocol uses three elements:
a User Agent, which is essentially the client that is registering services or locating services.
a Service Agent, which is essentially the daemon that holds registrations, and answers queries for service location.
a Directory Agent, which acts as an intermediary, to provide improved scaling.
Service Location Protocol provides capabilities for applications to register and deregister services, and to locate services by type, by host, or by attribute. The ability to do service location by attribute (with server side filtering based on LDAPv3 style filtering strings) is key to the scalability of Service Location Protocol from zeroconf up to enterprise size networks.
DNS Service Discovery is a way of using existing DNS Resource Records to locate services. Since a typical zeroconf client will already have a multicast DNS responder (to provide the name to address translation), this type of service location design may not require much in the way of additional resources.
Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this convention allows clients to discover a list of named instances of a that desired service, using only standard DNS queries. In short, this is referred to as DNS-based Service Discovery, or DNS-SD. | ||
| --draft-cheshire-dnsext-dns-sd.txt: | ||
DNS Service Discovery uses a combination of PTR, SRV and TXT records to locate services and their attributes.
PTR records are normally associated with reverse lookups (that is, given an IP address, PTR allows you to determine the name associated with that address). However PTR is really a generic mapping from one part of the DNS name space to one or more other parts of the DNS name space. PTR records are used to get from a generic class of services to a specific host.
SRV records are used to determine the port number that is to be used and relative weighting of each service
TXT records are used to convey attribute information
Consider the following example, loosely based on one provided in the Internet Draft:
To determine a list of FTP servers available on a network, you would issue a PTR query for _ftp._tcp.example.com.. This would likely return several Answers, such as fileserver1.example.com. and Big Cool Guy's oggs.example.com
To figure out to connect to the server, you might do an ANY query on Big Cool Guy's oggs.example.com, which might produce a SRV record that tells you to use port 2121, and to contact pc323.example.com. You may also get a TXT record, which would contain something like path=/pub/ms/oggs. So to connect, you need to contact pc323.example.com on port 2121, and change to directory /pub/ms/oggs.
If necessary, you would then do a normal DNS A query to determine the IP address of pc323.example.com.
While this is relatively simple, DNS Service Discovery does not have the deployment experience of Service Location Protocol. DNS Service Discovery also lacks some features that may make deployment in a larger situation difficult - in particular, it only supports client side filtering, so to find all the printers that can provide A2 size printing, you need to obtain the attributes (as TXT records) for every printer, and locally remove all those that cannot print on A2. As another limitation, the size of the attributes is limited by the TXT records.
| <<< Previous | Home | Next >>> |
| Technology - Part 2 - Name to Address Translation | Zeroconf in the home |