Authors Of Rdp Resource Discovery Protocol example essay topic

Abstract The evolution of dynamic resource discovery in mobile computing can be traced from its genesis in 1994 when the Resource Discovery Protocol (RDP) was proposed, and later implemented in 1996. Building upon these efforts, the International Engineering Task Force (IETF) formed a working group that has since released two working versions of the Service Location Protocol, the latest of which is beginning to gain acceptance in the wireless design community. This paper highlights prominent issues in both RDP and SLP protocols in a Mobile-IP setting. EVOLUTION OF DYNAMIC RESOURCE DISCOVERY FOR MOBILE COMPUTING Background 1. Mobile-IP protocols attempt to hide the affects of network movement from the application layer layers and applications running on the host are unaware of the separation between them and their resources. Since applications are predisposed to request resources from its home network, replies to the requests take longer and cause latency.

Their requests also create traffic at the network routers, thus affecting all nodes. Realizing this to be a major area of concern, Harry Harjuno and Charlie Perkins, the authors of RDP - Resource Discovery Protocol - began their research for improving the performance of applications running on hosts in a Mobile-IP setting, by allowing mobile clients to query local services, such as printers and web servers, without knowing network topology or naming schemes, as early as in 1994.2. In 1996, RDP emerged as a self-managed protocol, which a wireless client could use to request and access resources on a foreign network. To this end, the authors of RDP proposed a client-server model, which served as a basis for the protocol by which RDP is known today: the Service Location Protocol. 3. As a further development the International Engineering Task Force (IETF) also decided, in 1996, that the body of work accumulated by RDP warranted the nomination of the Service Location Protocol Working Group.

In 1997, the first version of SLP was released having been built on the foundation of RDP and in 1999, version 2 was proposed. PART I: RESOURCE DISCOVERY PROTOCOL 4. When the authors of RDP set out to design a protocol for network resources, they identified the necessary characteristics as being: (a) Scalability - as the intention was to have acceptance as an Internet application. (b) Self-Management - as the efforts of RDP must be transparent to both the user and the network administrators. (c) "Distributivity"- since the Internet contains many servers and many clients. (d) Compatibility- with administrative tools and existing network protocols. 5. RDP was successfully implemented on a twenty-machine network and its measured performance was admirable. The prominent features and shortcomings of RDP are highlighted below.

Features of RDP 6. RDP identifies the actors responsible for implementing the protocol, the syntaxes or "schemes" by which the actors communicate, and the overall process for resource discovery on a network. This formed the bedrock the Service Location Protocol. 7. Actors.

RDP identifies three major actors involved in the protocol's operation, whose roles are discussed below: (a) Directory Agent (DA). Also known as the Resource Location Server, the DA is a repository of addresses (URLs) where a client may find a service. URLs are stored in a database as strings and are queried once a service request is received. (b) Service Agent (SA). Also known as the Resource Client, the SA is a network device that provides a service, such as a printer or fax machine.

The SA is known either by URN or URL. (c) User Agent (UA). Also known as an RDP Client, the UA is a requester of services. It becomes aware of a DA through the DHCP server, which passes the DA's address in the Resource Location Server (RLS) extension upon connection. Once obtained, the UA unicasts its resource requests to the DA using the URN syntax. 8.

Schemes. RDP identifies schemes as the syntax, which the client and server must understand in order to successfully, communicate. Uniform Resource Names 9. The client-server nature of RDP required that the clients have a means of requesting a resource, such as a printer or fax machine. This had to be accomplished through a standardised, descriptive language that all actors of the protocol would understand. The solution was to identify a resource with a Uniform Resource Name (URN).

URNs are string based and have the following form: : / [rp]/ [na. .. 10. The value of service can be either n 2 l (name-to-URL resolution) or n 2 c (name-to-URC [or list of URLs] resolution) indicating that the requester desires a single resource or a list of them respectively. The value of rp is the resolution path (address) of the server, na is a naming authority by which to translate the URN, scheme is the URL scheme (described below) and key are keywords describing the URL. If neither rp or na are specified in a URN, the default values are used.

These values are the address of the server obtained via Dynamic Host Configuration Protocol (DHCP) and Internet Assigned Numbers Authority (IANA) respectively. Uniform Resource Locators 11. The server in the protocol's model needed a means of informing the client of the location of a requested resource. The solution proposed by the authors of RDP was to choose a Uniform Resource Locator (URL), which is the same format used by the Internet.

Like URNs, URLs are also string based and have the following form: : where a scheme is a means of understanding the scheme-specific-part. A common scheme used in Internet URLs is "http:" , which indicates hypertext transfer protocol is employed. Stressing human readability, the authors of RDP identify the scheme "printer:" in their implementation. Resource Registration Message 12.

SAs offering services, such as a printer or name file server, are required to register and de register their locations with DAs residing on their network. To accomplish this, they send a message to the DA that has the following format: : / [rp]/ [na]/; ; where reg|d ereg indicates if registration or de registration is to take place, rp is the resolution path, na is the naming authority, url is the address on the network where the resource is located, and desc N is a description of the URL. The esc 1 indicates that each descriptor is separated by an escape character Operation of Resource Discovery Protocol 13. The operation of RDP can be summarized in four steps: Resource Registration, DA Discovery, Resource Request, and Resource Reply. (a) Resource Registration. Using a Resource Registration Message, the SA informs the DA of its services and its location.

Once the DA receives the registration and determines the syntax to be correct, it is stored in the DA's database with the other URL. If the DA discovers that the received URL is already in the repository, no duplicate is stored. Incremental registration occurs when, should the URL of a received registration already exist in the database, only the descriptors not in the database are added. (b) DA Discovery. When a mobile client moves to a network, the network's DHCP server will assign a temporary address to the client.

Once the address is assigned, the client is able to request the URL of the DA using the Resource Location Service (RLS) extension (DHCP Option 11). Once this URL is received, it is stored in a flat file so that the client's applications may quickly obtain it to acquire resources "on the fly". (c) Resource Request. An application running on the UA determines it needs a resource and queries the flat file for the URL of the network DA. Once obtained, the UA unicasts a request for a service to the DA using the URN format. All requests are transmitted using UDP packets. (d) Resource Reply. Once a Resource Request is received and determined to have proper syntax, the DA performs a linear search of its database to match the scheme of the UA's URN to the scheme of the SA's URL.

A DA may have several matches to the request contained in tis repository. In the event that the service field of the URN is n 2 c, the DA searches the entire repository for all URLs matching the request. If the service field in the received URN is n 2 l, indicating only a single URL is desired, the DA will return the first matching URL it finds. Limitations of RDP 14. RDP lacked the formally defined actor roles that a polished protocol should have had. For example, it seems assumed that DHCP will always supply the UA with the DA's address.

No alternate plan has been catered for the event that no DA exists on a network. Such an occurrence would leave the UA in an awkward state. Further, the DA replies to the UA with the first URL it finds that satisfies the resource request, which suggests that no optimization for URL selection is considered. 15.

Moreover, RDP relies on UDP to communicate requests and replies. Since UDP datagrams are of fixed length and offer no sequencing mechanism, a scalability issue is created: a DA might be required to create an exceptionally long list of URLs for a requested service, and the length of the list might exceed the allocated space of a single datagram. There is no mention of how the protocol would manage this type of overflow error. 16.

Finally, RDP also has security issues. When the address of a DA is acquired, it is stored in a file on the client so that applications can easily find the address to which they direct requests. By design, RDP would publicly store an IP address on a snooping client computer thereby making it easy for him to identify resource requests that are routed through his machine. A denial of service attack can be readily constructed. 17. Calling the RDP a "protocol" seems to be a misnomer, however, it's simplicity makes it more of a "proof of concept".

Still, RDP capably identified the actors and schemes that were later adopted by the Service Location Protocol working group, making it a building block. PART II: SERVICE LOCATION PROTOCOL 18. The SLP continues the work of the RDP by identifying formal roles for the actors - specifically as they change with a network's size. All of the schemes and actor names identified in RDP have been adopted in SLP, although the URNs and URLs stand amended to include scopes, which are discussed below.

Scopes are used by SLP when service requests are made across a collection of connected subnets. 19. Also in developing a formalized process, the authors of SLP define the formats of the packets exchanged between the actors. All SLP messages begin with a 128-byte header. While, each of the other packets is mentioned in the protocol's implementation, the header packet is discussed below. Unlike RDP, the SLP supports the use of either TCP or UDP packets for messages.

Features of SLP 20. Scopes. The model inherited by RDP is one, which required a single DA, which is suitable for a medium sized network with a limited nodes and services. However, this does not scale well to a larger network, e.g. one comprised of a few interconnected subnets. A DA would be expected to handle the service registrations and replies for many SAs, which could severely hinder performance. For this reason, the authors of SLP devised a scheme for logically grouping DAs and SAs.

The groupings, called scopes, define a realm of responsibility that can be administratively assigned (scope = MATH DEPT) or geographically assigned (scope = DOWNTOWN) by a network administrator. A service request originating from a visiting host might have scope contained in the URN. If this is the case, only those DAs within the scope respond. 21.

Protected Scopes. SLP introduces a security feature in its implementation called Protected Scopes. Within a protected scope, an SA seeking registration will have to provide cryptographically strong authentication to the DA responsible for the scope. This is done with the use of several authentication extensions employed by SLP. 22. Multicast Service Discovery.

The authors of SLP also proposed improvements to RDP for operations in small networks. When a network consists of only one or two nodes and services, it becomes unnecessary to have a DA reside on the network, as it does not warrant there being a repository of service URLs. In this case, SLP allows the UAs to request services directly to the SAs on a network with a multicast service request sent to the service-specific multicast address. SAs are required to listen for these requests and, once one is detected, are required to respond to the UA advertising its URL.

The UA multicast the service request and collects URL of the available SAs. After a determined period of time (3 seconds) the UA re sends the request, together with a list of previous responders. Only those SAs not already on the list can respond. This continues until the UA deems the list of available SAs complete. 23.

If a UA wishes to be sure that SAs were authorized to provide the service they advertise, then it should request services from a protected scope, which can be discovered from the DHCP server. Operation of Service Location Protocol 24. With the advent of scopes, service discovery in SLP becomes more complicated than compared to RDP. What was once done in four steps now requires eight steps, as brought out in subsequent paragraphs. 25. Service Registration.

An SA begins the registration process by identifying DAs on its network, and does so with a Srvreg (with Function = 0). The packet is sent in multicast to the service-specific multicast address to which all DA's are required to listen. All DAs present on the network respond to the DA Discovery with a DAAdvert. The SA creates a list of all DA's to respond and sends out another DA Discovery message, with the list attached.

All DAs in receipt check the list and, if they are not on it, reply with a DAAdvert. This process continues until SA detects no new replies. 25. The SA sends a SrvReg datagram to the responding DAs. Within one of the datagram fields is a URL Entry that contains the address of the SA and information specific to the type of service the SA provides (such as description keys). The DAs send Srv Ack to confirm registration OR to indicate an error has occurred.

Upon registration, each service is assigned a lifetime for which it is valid. This lifetime is set in one of two ways: either the DA assigns a default value (3 hours) or the SA chooses a lifetime within the header of the SrvReg datagram. Once the service is successfully registered, it remains valid until the SA voluntarily de registers the service or when its lifetime expires. 25. DA Discovery. When a UA requires service, it sends a DA Discovery packet in multicast.

This is done in the same fashion as with the SA: by sending a SrvRqst (with a Function = 0). Each DA in receipt of the UA's packet replies with a DAAdvert. 26. Service Request. The UA reviews the scopes of the replying DA's and sends a SrvTypeReq packet to those in the correct scope. The URN describing the requested service is sent within the datagram fields.

27. Service Reply. Queried DA's search for a match of the requested service and a SrvTypeRply packet is sent with the URL of a matching SA. Limitations of SLP 28.

Although a major improvement over the RDP, the SLP still has scalability issues in that SAs are required to register with each DA within earshot (i.e. a TTL of 22). Many SAs create large repositories for the DA to manage and large URL lists for the UAs seeking resources. Also, many DAs create traffic on the network in the form of unsolicited DA advertisements and service registrations. SLP caters for alleviation of some of this by allowing a network administrator to configure Sas, so that their service registrations are sent to a limited number of DAs. However, this human intervention violates the desire for self-management (ex the RDP). 29.

Another scalability concerns service lifetime. If the SA chooses a short lifetime the effects might be continuous registration between it and the network DAs. As of SLPv 2, there is no lower bound on time limits (other than 0). 30. Further, SLP has security issues in that is does not provide confidentiality.

Because the objective of the protocol is to advertise services to a community of users, confidentiality is assumed to be unnecessary in unprotected scopes. This allows a malicious user to advertise services on servers controlled by him and to gain access to an unsuspecting client's confidential information. With this in mind, possibilities for denial of service discussed in the RDP remain relevant even in SLP. 31. SLP also seems to have the same lack of optimization that RDP had, in the way a UA selects a DA. In its current form, SLP allows the UA to select any one DA when several have been discovered.

This implies that the DA located the most hops away can be selected over the DA that is the closest. The result is unnecessary traffic at intermediate nodes. 32. SLP has language translation issues as well. Currently, SLPv 2 only support US-ASCII and thus does not recognize some characters used by non-English languages. In the event that one of these characters is encountered, SLP performs a best attempt at translation and does not guarantee correctness.

A UA is therefore not guaranteed to receive the URL of a requested service even though it may exist on the network. SLP: Comments 33. The designers of SLP have made progress since inheriting RDP in 1996. Some issues such as scalability and security have been addressed with scopes.

Further the use of multicast allows for the protocol to be used on networks without DAs, thus giving a UA an alternative option that was not available in RDP. 34. SLP's most visible improvement has been in it's use of formatted data headers and packets. Its use of TCP is also an improvement.

35. However the biggest issue that remains with SLP is its scalability. Even with scopes, DA repositories can grow to be unmanageably large. Adding another (e.g. sub scopes) would not seem to be the answer, either, as requests for services would experience delays of a polynomial factor. Perhaps a new approach to the issue is required. CONCLUSION 36.

The Service Location Protocol provides a means of discovering and selecting resources without being tethered to a network. Although SLP has security and language issues, the members of the SLP working group are working to resolve those issues. Considering the progress made from RDP to SLPv 2, there is cause for optimism. It would seem that the overall acceptance of SLP as an Internet application would depend upon the working group's ability to solve scalability issues, for reasons already mentioned. 37. Perhaps as the Wireless Application Protocol (WAP) becomes more prevalent in wireless applications, SLP might become more useful in the location of the Gateways that speak to handheld devices.

The location and selection of these servers based on proximity might reduce delays caused by network traffic-an original concern of the RDP. 38. Both the protocols discussed seem to focus on how mobile clients can find hardware devices when visiting a foreign network (in all examples in the cited references, mobile clients were looking for and selecting printers). It may be that the SLP working group is developing its application for choosing "soft" resources as well as hardware devices. Applications can link to the libraries, as they are needed.

Bibliography

Charles Perkins et al, "Transparent Resource Discovery for Mobile Computers", Proceedings of Workshop on Mobile Computer Systems and Applications, I Computer Society Press, Dec '94 Charles Perkins, and Harry Harjuno, "Resource Discovery Protocol for Mobile Computing", Mobile Networks and Applications, Vol. 1, No. 4, Jan 1996, p 447-55 RFC 2165-Service Location Protocol version 1 RFC 2608-Service Location Protocol version 2 RFC 2609 Service Templates and Service Schemes.