Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-svrloc-wasrv-00.txt < prev next >

Wrap

Text File | 1997-07-25 | 40KB | 896 lines

Internet Engineering Task Force Service Location WG Internet Draft J. Rosenberg, B. Suter draft-ietf-svrloc-wasrv-00.txt Bell Laboratories July 1997 H. Schulzrinne Expires: January 1998 Columbia University Wide Area Network Service Location STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. 1 Abstract This document discusses the problem of service location in wide area networks. This problem arises when a user wishes to locate some ser- vice, such as a media bridge, internet telephony gateway, H.323 Gate- keeper, unicast to multicast bridge, etc, which has some desired characteristics, but whose location (in terms of IP address, domain, or geographical location) is completely unknown, and may be anywhere on the public Internet. We focus on the problem of locating Internet Telephony Gateways (devices which connect an IP host to a POTS user). This particular location problem is characteristic of the general problem; furthermore, location of these devices is particularly dif- ficult. Generally, the service location mechanisms need to be invoked for every call setup. This implies that the call setup delays will include the time to locate the gateway, and these delays should therefore be kept to a minimum. With large numbers of gateways, the location mechanisms can potentially become a network, processing, and storage intensive operation. A solution to the gateway location prob- lem must therefore be efficient and scalable in use of bandwidth, CPU Rosenberg et. al. July 24, 1997 [Page 1] Internet Draft Wide Area Location July 1997 power, and disk storage. Furthermore, relaying internet telephony calls to the PSTN results in cost for the gateway provider, which must somehow be passed on to the remote user. This requires security mechanisms to provide authentication in an international environment. We propose a solution to the wide area service location problem as an extension to the existing Service Location Protocol [5]. The solution relies on a scalable multicast advertisement of services to directory agents, service specific directory agents called brokers, optional service advertisement agents called notaries, new search capabili- ties, and support for billing. 2 Introduction There has been much attention recently to protocol support for the location of services on the Internet. This work includes DNS records for finding services in a particular domain [1][2], and for finding fax gateways in a particular telephone exchange [3], DHCP for dynamic discovery of local services upon cold-start [4], URNs for location independent naming and location of network resources [12][13], and most importantly, the Service Location Protocol [5] for location of services in an administrative domain. Unfortunately, none of these solutions adequately support location of services across wide area networks, which we believe to be a key aspect of the general service location problem. This document describes an extension to the service location protocol for discovery of wide-area services. There are a number of examples of wide area services. One is media bridges (also known as Multipoint Control Units, or MCU's), which are devices used for mixing voice or video together for multipoint con- ferences. Another might be a media server, which contains movies and multimedia accessible to the user for playback. Another example are Internet telephony gateways. These devices allow Internet hosts to communicate with standard POTS telephone users by translating Inter- net telephony to traditional telephony. Yet another example is a mul- ticast to unicast bridge, which would allow unicast-only endpoints to receive Mbone broadcasts (an admittedly non-scalable and self- defeating application). There are two reasons why such services need not be located in the same administrative domain as the client. The most important reason is that the service simply may not be provided yet (or may never be provided) by my domain. Consider a user who subscribes to a small ISP. This ISP is not likely to support media bridges or telephony gateways. This should not prohibit the client from using these ser- vices, no matter how remote the server may be. Secondly, in many cases it may not even be desirable for the service to be located in a client's domain. The best example of this is the telephony gateway. Rosenberg et. al. July 24, 1997 [Page 2] Internet Draft Wide Area Location July 1997 To reduce costs, as an IP host, I would like to use a gateway which is closest to the telephone I wish to talk to. Consider an IP host residing in California who wishes to call a normal telephone in France; the ideal server may be a gateway in France, almost across the world from the client. It should be noted that the use of the word "service" in this docu- ment includes, but is not restricted to, network services. It may also include services like Internet access, pizza delivery, airline reservation, online bookstores, or banks. Any service which can be accessed electronically, and which has attributes which can be expressed in some form, can be found via this protocol. 3 Problem Definition We formally define the wide area service location problem as follows. A client wishes to find a server that provides a service. There are no restrictions on the name space, IP address space, geographical location, or autonomous system where the server may be located. Fur- thermore, the client has no knowledge of the location of the server. It has only a definition of specific service attributes or con- straints (e.g., supported protocols) which are desirable or metrics to minimize or maximize (e.g., cost, quality, distance). In the case of wide-area services, we expect some servers to charge for features they provide. This implies that cost is another attribute which needs to be supported by servers. Unfortunately, cost is not always just a simple number. It may depend on the duration of usage of the service, the specific nature of the service, or even the time of day during which the service is used. Consider Internet tele- phony gateways. They will charge the client some amount for the por- tion of the call carried over the PSTN between the gateway and the final destination. Unfortunately, telephone cost structures range from extremely simple (flat rate) to wildly complex (20 cents for the first minute on weekends, 10 cents for each minute thereafter, but only to Canada). Since the distance (in terms of IP hops or delay) between a client and a possible server may be large, the time required to access the service may be large. Again, consider the case of an Internet tele- phony gateway. In some cases, an IP host may wish to call a POTS end- point from an IP phone, but may not care about the cost of the call. What may be important is having the lowest end-to-end delays, and as little loss as possible. This would imply usage of a gateway closest to the host. Media bridges are another example. To reduce end-to-end delays, a host may want to use the bridge closest to it (or perhaps located at the centroid of the users being bridged), and the protocol should support searches for such servers. Rosenberg et. al. July 24, 1997 [Page 3] Internet Draft Wide Area Location July 1997 The protocol should scale so that all Internet hosts could act as clients, and there could be tens of thousands of servers for each service. Since the time required to locate a service impacts the overall delay seen by the user for that service, location times should remain relatively constant as the number of clients and servers grow. The control traffic used by the protocol should also scale well, and not impose an undue burden on the network. 4 Alternate Solutions A brief mention is in order a few alternative solutions for wide area service location. One is web search engines, and the other is DNS. Web search engines use automated programs, called web bots, to search the web, and index and categorize pages as they go along. If servers use web pages to describe the services they offer, the web bots would collect this information and allow a user to query the resulting database to locate a service. The user could choose between various search engines (information brokers) based on their user interface, size of their database, or the power of their query language. This solution, however, has some serious drawbacks. Most current search engines are simply based on keyword searches on indexed web pages, and lack the precision to locate a specific service precisely (anyone who has done a search which returned over ten thousand matches knows this problem). Even cooperative approaches (based on indexing meta information within the html, for example) still require the search engines to periodically query a large number of servers. The web bots have no way of knowing when information at a server has changed. This means that data can remain out of date for long periods of time (this can be devastating if this data reflects service cost, for example), or web bots will have to increase the frequency of their queries to any particular server, increasing network traffic. This solution also places the burden of service location in the hands of a few, dedi- cated search engines. Adding more of them can ease the processing load, but at the expense of even more webbot traffic. Lastly, web- based searching is designed for human interaction, and not for auto- mated processes. For these reasons, we feel that web search engines are not viable as a long term solution to the problem. Another alternative is to use DNS. Consider the case of telephony gateways. Each calling area (the 415 area code in the US, for exam- ple) can map to a particular domain name. This domain name then points to all of the gateways which can provide service for this calling area. If a client wishes to call a certain area, it con- structs the domain name, looks it up, and then gets a list of poten- tial servers. This approach has many drawbacks. First, since all gateways connected to the PSTN can potentially call every PSTN end- point, every gateway can provide service to every single calling Rosenberg et. al. July 24, 1997 [Page 4] Internet Draft Wide Area Location July 1997 area. This means that the DNS entries would list every gateway for each calling area. If the list of gateways for each calling area is to be restricted (which it must), who gets to decide which gateways are allowed to service various calling areas? The DNS solution does not allow one to find a gateway which meets certain criteria (support for the G.723 speech codec, for example) without querying the server directly (which does not scale). It also tends to cause a lot of traffic to pass through the root DNS server. For these reasons, we do not feel that DNS is a viable long term solution either. 5 Service Location Protocol Limitations The Service Location Protocol already meets many of the criteria above. However, it was designed for use only within a single adminis- trative domain. It suffers from a number of problems when one attempts to apply it to a general wide area network with thousands of servers and millions of clients. The current architecture is centered around the concept of a direc- tory agent, or DA. This device is a server which collects information about services provided by various service agents (SA's) across the network. The SA's register the services they provide directly with the DA. Clients (also known as user agents, or UA's) wishing to locate a service send a query to the DA, which then searches its database for matches. The DA then returns the list of servers to the client. Clients and SA's must know the IP address of the DA. This can be learned in one of several ways: through static configuration, through DHCP, through multicast advertisements from the DA, or through increasing-scope multicast searches performed by the client or SA. We have identified the following difficulties in scaling the current service location architecture to wide area networks: 1. Registrations of services from SA's to DA's are asynchronous, and the soft-state refresh interval is fixed (the recommended value is around three hours). This means that if thousands of servers attempt to register, the DA may be swamped with bursts of messages. As the number of servers grows, this problem worsens. 2. SA's must know the location of all DA's. In a small administrative domain, this is easy. But in a wide area Internet, this is virtually impossible. Having fixed tables of DA's does not scale well, and is not dynamic enough. Using the multicast searching technique will cause an overload on the network, since the scope of such searches is neccesarily unbounded. Having DA's advertise their presence works better, but still causes traffic. With fixed soft-state refresh intervals, the bandwidth used grows linearly with the number of DA's Rosenberg et. al. July 24, 1997 [Page 5] Internet Draft Wide Area Location July 1997 present in the network. 3. As the number of servers and services grow, the disk space required for a DA to store information about all of them is exces- sive. DA's must somehow be able to provide service location for only a subset of services. 4. In a wide area network, authenticating services at either the DA or UA is much more important than in an administrative domain. We expect, therefore, that all service advertisements will contain URL and attribute authentication blocks. However, it may not be possible, in all cases, for the DA or SA to authenticate every service. This may be for any number of reasons: lack of availability of public keys for all services, regulatory reasons, etc. Some additional support for a hierarchy of authentication is required. 5. The current attribute query language has no support for choosing a service based on minimizing or maximizing some function of an attribute. This is a requirement for allowing service location based on cost minimization. Furthermore, the simple attribute matching rules are not sufficient for describing the possible costs of a phone call. 6. The current mechanisms provide no way to find out the distance between a server and a client, even with perhaps marginal precision. This is required to choose servers based on their proximity to the client. 6 Proposed Solution We propose a set of backwards compatible extensions to the Service Location Protocol which resolve all of the above difficulties. We describe the basic mechanisms only, much of the detail remains to be worked out. 6.1 Multicast Registration First, in addition to SA registrations being unicast, we allow for multicast registrations. A set of 1024 contiguous multicast addresses are defined, with each service mapping to one of these addresses via a string hash. (Note that these addresses are different from the 1024 currently used in the service location protocol for clients to find SA's directly). Any DA interested in providing location services for a service listens to its multicast address. In addition, any server wishing to advertise a service also listens to its address. By lis- tening to the address, a server wishing to advertise on it can keep track of the number of other servers also advertising. Let's say a server hears N other servers. We define a parameter Rosenberg et. al. July 24, 1997 [Page 6] Internet Draft Wide Area Location July 1997 CONFIG_INTERVAL_12 which is the average interval of 1 kbyte packets to be transmitted, summed across all servers, into the multicast group. Each server wishing to send an advertisement of size K will periodically send the advertisement with a period T equal to: T = R(1/2) max(CONFIG_INTERVAL_13 * F(age), N * CONFIG_INTERVAL_12 * K / 1024) F(age) is a function which starts at some fractional power of two, -CONFIG_INTERVAL_14, whenever an advertisement is different from the previous. For each subsequent advertisement which is not different from the previous, F(age) doubles, until it hits 1, at which point it stops. We also define R(1/2) as a random variable uniformly dis- tributed between 1/2 and 3/2. For example, say that CONFIG_INTERVAL_12 is 64 ms. This means that the total rate of pack- ets sent into the group will be 128 kb/s when group sizes are large. If there are 1000 servers, each sending 1 kByte packets, each one will get to advertise once a minute. When group sizes are smaller, the packet rate remains at 1 every CONFIG_INTERVAL_13 (perhaps one per hour) during steady state. However, when an advertisement changes, the rate can temporarily increase (but not above 128 kb/s) to hasten the broadcast of this announcement. As a further enhancement to improve scalability, timer reconsidera- tion should be used [11]. This algorithm requires end-systems to recheck the validity of their event timers before sending a packet. The validity is based on whether the perceived multicast group size has changed since the timer was set. If the perceived group size has grown, packet transmission is delayed in accordance with the most recent group size estimate. This approach will help reduce packet transmissions from servers which boot up, join their multicast group, and initially see only one server: themselves. This mechanism allows for the number of servers to grow without caus- ing an increase in the bandwidth used on the multicast address. A similar mechanism is used in RTP [9] to provide scalability, and has been proposed as a general scaling mechanism for soft-state protocols [10]. The advantage of this approach here is to solve two of the above limitations. Now, SA's do not need to know the actual addresses of DA's. This eliminates the need for wide-area multicast searches and/or DA advertisements. It also makes the system dynamic. As soon as a new DA is turned on, it can immediately learn about new ser- vices, and this process is transparent to the SA's providing the ser- vice. It also solves the problems of excessive load on DA's. The rate is now finely controlled, independent of the number of SA's. Rosenberg et. al. July 24, 1997 [Page 7] Internet Draft Wide Area Location July 1997 It should be noted that this advertisement mechanism is used in other protocols. For example, SAP [8] is used to advertise multicast ses- sions on the Mbone. With this protocol, however, a client must wait a substantial amount of time to collect announcements about all of the current sessions. This is because the bandwidth allocated for the protocol is constant. So, as the number of broadcasters (servers in our case) increases, the amount of time required to fill the database grows as well. For this reason, this advertisement mechanism alone is not sufficient for wide area server location. It would also place an undo storage and processing burden on clients. SA's that are not multicast capable or which do not want to subscribe to the service advertisement multicast group for reasons of bandwidth or complexity may use a proxy SA or notary to diffuse their service advertisements (sec 6.5). 6.2 Service Specific DAs: Brokers We define a new type of DA, called a broker. A broker combines fea- tures of a DA and an SA. Like a DA, it accepts service requests and service type requests, and answers with service replies and service type replies. The main difference is that it provides location ser- vice for only a subset of services. This is required in order to scale the disk storage and processing requirements for DA's. It is also desirable since different services may have different require- ments for matching client requests. For example, the Internet tele- phony gateway service may often require searches for servers which provide the cheapest cost for calling France. Database searches can be optimized for this kind of query, but only if the DA knows that it will receive mostly or only these type of service requests. Unlike a DA, however, a broker will not respond to directory agent discovery requests, nor will it send directory agent advertisements. Instead, it will send service advertisements, like an SA. If a broker offers service location for service X, then it will advertise itself as offering service X-broker. For example, a broker offering printer broker service may use a URL: service:printer-broker://mymachine.mydomain.com:800 Brokers themselves can have various attributes which define the bro- ker service they provide. For example, this might be a typical attribute specification for a Internet telephony gateway broker: (NUMBER_GATEWAYS = 1000), (VERIFICATION_LEVEL = STRONG) This would define this telephony gateway broker as having a database of around 1000 gateways. The verification level attribute indicates Rosenberg et. al. July 24, 1997 [Page 8] Internet Draft Wide Area Location July 1997 that this broker provides strong assurances of the correctness of the gateway attributes it stores. The ways in which brokers register with DA's can be varied. Some bro- kers may wish to multicast their service advertisements. Other bro- kers may be used just for clients in an administrative domain, and therefore will perhaps use currently defined techniques to locate the DA's in their domain, and register with them. Or, service advertise- ments can be sent by some non-standard, out of band technique. Con- sider a small ISP who has a DA for its customers, but no brokers. The ISP can essentially lease broker service from a nearby, larger ISP. The small ISP can just manually enter the service advertisements from the big ISP brokers. Or, the small ISP can tell the big ISP the IP address of its DA, so that the big ISP can have its brokers directly register across the domain boundaries. Brokers can be additionally programmed to implement policy local to the administrator of the broker. This policy may restrict the set of servers whose advertisements are kept by the particular broker. For example, a major ISP is running a broker service for telephony gate- ways for its customers. The ISP may decide that the broker should reject all internet telephony gateway service advertisements from servers run by a competing ISP. As another example, a broker may have limited disk space, and may drop advertisements for servers which it believes are unlikely to be used by any of its clients, based on past history logs of service requests. It should be possible for any sort of policy to be implemented. However, brokers should indicate the policy attributes in the service advertisement from their broker. The use of brokers for a particular service also adds more scalabil- ity. Requests requiring attribute minimization can be considerably more CPU intensive than simple lookups. As the queries for a particu- lar service increase, and begin to exceed the processing capabilities of a broker, additional brokers can be added to distribute the load. This load distribution can be implemented easily in the DA, since brokers are registered through them. The entire process becomes transparent to the clients, and to the servers. The main limitation to scalability for the brokers is the processing burden to search a large number of records. If the number of servers for a particular service begins to exceed several tens of thousands, the storage requirements for them, and the time for even a single search of the database for a match, can become excessive. In this scenario, brokers always have the option of implementing policy to restrict the size of the database. As faster machines and bigger disks become available, these policies can be lifted. Furthermore, such restrictions open up the possibility of market competition for broker service. If a broker provider is willing to buy a big enough Rosenberg et. al. July 24, 1997 [Page 9] Internet Draft Wide Area Location July 1997 disk and fast enough machine to store and search every server, it can attract more customers to its broker service. This leads to the final distinction between DA's and brokers. Since a broker service may not be local to my autonomous system, it is very possible that there may be a charge for the service. In that case, additional fields in the Service Query messages may be required to allow for client-broker authentication and charging. 6.3 Adding the DISTANCE attribute Another requirement is for clients to know, at least roughly, how distant a server is. It is desirable for a client to include some kind of distance metric in a service request to a broker. To support this, we propose that all servers place a timestamp in their service adverisements. When the advertisement arrives at a bro- ker, the broker can compare the timestamp against the current time, and then compute an estimate of the one way delays. In scenarios were services are located across wide area networks, packet delays are likely to be dominated by propagation delays. This implies that timestamp estimates should remain relatively constant, even as traf- fic loads vary. We call this one-way delay the DISTANCE attribute. The approach has obvious drawbacks. It requires clock synchroniza- tion, but the accuracy need not be perfect (a few milliseconds dif- ference is fine). It only makes sense when packet delays are due mainly to propagation delays. The figure gives the one-way delay from a server to the broker. This may not be the same as the one-way delay from a client to the server, especially if the client is not close to the broker. Despite these drawbacks, it seems to be the only reason- able solution which is both practical and scales. The major advantage is that it requires no additional network traf- fic, and therefore scales extremely well. An alternative solution would be for servers to include in all ser- vice advertisements an attribute called INITIAL_TTL. This attribute indicates the value of the TTL field used in the IP packet containing the advertisement. When a broker hears this advertisement on the mul- ticast address, it notes the TTL in the IP packet when it arrived, and the value of the INITIAL_TTL attribute. From this, a broker can ascertain the number of hops from the server to itself. The problem is that the Unix and Windows sockets interface do not allow an appli- cation to read the TTL of a received packet. This makes this solution impractical. 6.4 Adding support for cost minimization Rosenberg et. al. July 24, 1997 [Page 10] Internet Draft Wide Area Location July 1997 To support searches for the cheapest service, two new operators, max and min, should be added to the allowable set of operators on attributes. Service requests must be limited to one min or max opera- tor per expression, in order to be well defined. In order for the min or max operator to be applied, the broker must know the destination telephone number, and an estimate of the call duration. We propose that this information be specified by the client in the same manner that attribute constraints are specified. For example, the following might represent a request for an Internet telephony gateway to com- plete a call to the Hotel Arabella in Munich: internet-gateway//( &(CALL_DESTINATION == 49 89 92 32 44 40) (CALL_DURATION == SHORT) (DISTANCE < 10) (SPEECH_CODER == G.729) (min COST)) In this query, the client is specifying that a gateway is needed which supports G.729, and whose distance from the client is less than 10 hops. These are attribute constraints. The distance metric is not a true attribute, however; it is computed by the broker for each client separately. The remaining data specify to the broker the desired destination and estimated call duration, and then specifies that cost is to be minimized. In the case of Internet telephony gateways, describing the cost func- tion is a nontrivial process. Our proposal is to use CIDR [6] like aggregation, but applied to telephone numbers. The cost is specified as a list of prefix, cost structure pairs. The prefix indicates the range of telephone numbers, and the cost structure describes the cost for reaching that range of numbers. The cost structure can be repre- sented by some simple syntax which is capable of expressing concepts such as flat rates, sums, days, and times. For example, the following might be used to describe the cost as seen by a gateway in Califor- nia: 1 415 822, ($0.1) 1 415, (($0.1) PLUS ($0.03 per MINUTE)) 1, (($0.1) PLUS ($0.1 per MINUTE)) 49, ($0.03 per MINUTE) 0, ($0.2 per MINUTE) Rosenberg et. al. July 24, 1997 [Page 11] Internet Draft Wide Area Location July 1997 The length of the prefix is given implicitly by the number of digits before the comma. This gateway seems to be located in the 415 area code, in the 822 exchange, to which it provides the cheapest service. The gateway is also having a special on calls to Germany - just 3 cents per minute. Wide area service location is meant to operate over the world wide public Internet. The problem of how to represent cost (and other attribute values) in an international context is difficult. One solu- tion might be to fix cost and attribute representation to an arbi- trary currency and language (e.g. dollar and English). An alternate solution is to advertise cost in the local currency, and then have the broker perform currency translation periodically. 6.5 Notaries The final addition is a new device which we call a notary. Its pur- pose is to lessen the burden of authentication which is placed on DA's and brokers or to support non multicast capable SA's. Instead of registering directly with all the brokers by multicasting its adver- tisement, an SA will instead register in some way with a notary. It is the job of this notary to provide authentication for the SA's which it represents. Once authenticated, the notary acts as a proxy for those SA's, multicasting the advertisements for them. The form of the service advertisements is nearly identical to that of an SA. The exception is that the authentication block is used to authenticate the notary, and is the same authentication block for all SA's being advertised from this notary. This lessens the burden of authentica- tion to that of a single notary, instead of many SA's. Due to legal problems regarding cryptographic technologies a unified strong authentication mechanism may not be available world-wide very soon (or ever). The use of notaries allows the SA's to authenticate themselves to the notary by any local or proprietary scheme. In general, for services that involve billing, authentication of the server may not be enough. The user may want some assurance about the trustworthiness of the remote service operator. Notary services could be provided by authorities of sufficient influence and reputation to be trusted by users. Such authorities may, for example, police misbe- having service provides they represent, using non-electronic means (such as auditing financial records, etc.). This kind of model already exists; credit card companies will absorb the costs of fraud- ulent vendors, and revoke their capabilities to use the credit card to charge customers. It is not our objective to specify the nature of the verification procedure performed by the notary owner. Instead, all that is needed Rosenberg et. al. July 24, 1997 [Page 12] Internet Draft Wide Area Location July 1997 is a way to classify the level of assurance that a user can expect from the notaries' authentication, and place this information as an attribute describing the notary service itself. The end result is a transitive chain of trust, similar to the mecha- nisms used in PGP [7]. 7 Conclusion We have described the problem of location of services in the wide area Internet, and noted the drawbacks of the Service Location Proto- col for such uses. We then proposed several backwards compatible extensions for resolving these drawbacks: multicasting of registra- tions, service specific DA's called brokers, distance metrics, cost structures for billing, and hierarchical authentication services via notaries. 8 Security Considerations The problem of service location involves potential danger of denial of service or fraud. Anybody can potentially advertise many bogus service records and swamp the databases of the brokers to uselessness. Authentication limits the damage a single individual can do as brokers would become suspicious if a unknown entity suddenly starts advertising thousands of servers with optimal characteristics. Even with authentication a large number of individuals could still produce the same effect by coordinating their efforts. Should this become a problem brokers would have to require certification by a "known" notary before they consider a service advertisement. For services that involve billing, like internet telephony gateways, the possibility of deliberate misinformation by a service operator to attract and "trap" customers becomes likely. It is easy to imagine that some off-shore gateway operator might advertise very cheap rates and then charge exorbitant rates to the users credit card. It is for this reason, among others, that we propose the notary server, as dis- cussed above. It is also possible for an SA to misbehave by ignoring the scaling rules for multicasting advertisements. Although it is simple to detect this kind of behavior and ignore the frequent messages, the excessive traffic may cause valid advertisements from other users to be lost. However, this problem is a generic one for multicast, and we do not attempt to treat it at this level. 9 Bibliography Rosenberg et. al. July 24, 1997 [Page 13] Internet Draft Wide Area Location July 1997 [1] A Gulbrandsen, P Vixie, A DNS RR for specifying the location of services (DNS SRV), IETF Request for Comments 2052, October 1996 [2] R. Moats, M. Hamilton, P. Leach, Finding Stuff, IETF Internet Draft draft-ietf-srvloc-discovery-02.txt, Work in Progress [3] C. Malamud, M. Rose, Principles of Operation for the TPC.INT Subdomain: General Principles and Policy, IETF Request for Comments 1530, October 1993 [4] R. Droms, Dynamic Host Configuration Protocol, IETF Request for Comments 2131, March 1997 [5] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, Service Location Protocol, IETF Request for Comments 2165, June 1997 [6] V. Fuller, T. Li, J. Yu, K. Varadhan, Classless Interdomain Routing (CIDR): an Address Assignment and Aggregation Strategy, IETF Request for Comments 1338, September 1993 [7] The International PGP Homepage can be found at: http://www.ifi.uio.no/pgp [8] M. Handley, SAP - Session Announcement Protocol, IETF Internet Draft, draft-ietf-mmusic-sap-00.txt, November 1996. Work In Progress [9] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real Time Applications, IETF Request for Com- ments 1889, January 1996 [10] P. Sharma, D. Estrin, S. Floyd, V. Jacobson, Scalable Timers for Soft State Protocols, in Proceedings of IEEE Infocom, Kobe, Japan, 1997. [11] J. Rosenberg, H. Schulzrinne, Timer Reconsideration for Enhanced RTP Scalability, submitted for publication in the Proceed- ings of IEEE Infocom 1998 [12] R. Moats, URN Syntax, IETF Request for Comments 2141, May 1977 [13] R. Daniel, M. Mealling, Resolution of Uniform Resource Identi- fiers using the Domain Name System, IETF Request for Comments 2168, June 1997 10 Authors Addresses Jonathan Rosenberg Lucent Technologies, Bell Laboratories Rosenberg et. al. July 24, 1997 [Page 14] Internet Draft Wide Area Location July 1997 101 Crawfords Corner Rd. Holmdel, NJ 07733 Rm. 4D-534B email: jdrosen@bell-labs.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu Bernhard Suter Lucent Technologies, Bell Laboratories 101 Crawfords Corner Rd. Holmdel, NJ 07733 Rm. 4G-531 email: suter@bell-labs.com Rosenberg et. al. July 24, 1997 [Page 15]