Internet Engineering Task Force Service Location WG Internet Draft J.Rosenberg,H.Schulzrinne,B.Suter draft-ietf-svrloc-wasrv-01.txt Bell Laboratories Nov. 14, 1997 Expires: May 1997 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 We propose extensions to the Service Location Protocol (SLP), which allow for registration and discovery of services scattered across the wide area network. We make use of scalable wide area multicast to allow agents within an administrative domain to learn about services within other domains. We also describe a new agent, the Brokering Agent (BA), which is responsible for providing information about a particular set of services types. 2 Introduction and Motivation The Service Location Protocol (SLP), recently approved as RFC 2165 [1], with version 2 under development [2], provides an automatic way for clients to discover services within an administrative domain. Clients can select services based on various attributes which describe the service. The basic mechanism involves Service Agents (SA)'s, which represent a service, registering their service attributes with a Directory Agent (DA). User Agents (UA's) query the Rosenberg et al. November 20, 1997 [Page 1] Internet Draft Wide Area Location Nov. 14, 1997 DA with a set of desired attributes, and the DA replies with a set of servers meeting the requirements. SLP also specifies operation when there is no DA, by making use of multicast queries. SLP is designed specifically for use within an administrative domain. Its use of uncontrolled multicast for service queries and DA discov- ery make it unscalable to wide area usage. However, there are many cases where clients may wish to access services provided outside of their administrative domain. This may be because the client's domain does not provide the service, or because the servers inside the domain do not meet the required criteria. Examples of such services include media servers, telephony gateways, conference bridges, certi- fication authorities, etc. To facilitate the automatic discovery of such services, explicit pro- tocol support is required. Such a protocol must meet a number of cri- teria: 1. It must be scalable in terms of network usage; bandwidth con- sumption in wide area accesses must be limited. 2. It must allow for multi-criteria selection. 3. It must allow a user to locate a service about which it has no apriori hints for its location (such as the domain the service is located in). This is key. If a client wishes to contact a media server, it will not know that the media server is in abc.com or nbc.com; it only cares that the server meets the required service criteria. 4. It must be possible for an administrator to easily control the set of services which can match a client request. This will allow ISP's, for example, to filter services for its users, or prevent its users from accessing certain services. 5. It must allow for universal service. In other words, the pro- tocol should operate so that any host on the Internet can potentially be a client for a service. Of course, local poli- cies can restrict certain clients from accessing a service, but it must be possible to provide universal service. 6. Locating a service should be fast. 7. It should be lightweight. There are other methods which can be used to locate services in a wide area network. These include the use of SRV records [3] [4], and other approaches which leverage off of DNS, the world wide web, and large Rosenberg et al. November 20, 1997 [Page 2] Internet Draft Wide Area Location Nov. 14, 1997 distributed databases, such as X.500 [5] or whois++ [6]. The DNS based approaches generally require the user to either know the domain in which the service is located (which isn't generally known), or require the service to be mapped into some hierarchy based on a single attribute (therefore eliminating multi-criteria selection). The world wide web allows users to search for services. However, the approaches used thus far are not amenable to automation, and require significant human inter- action to locate a service. Furthermore, they are generally based on pull technologies, which means that services are often out of date. Hierarchically distributed databases like X.500 have the same problem as DNS - they require services to be mapped into a strict hierarchy, which does not exist for multicriteria selection. Whois++, through centroids, allows for non-hierarchically organized databases, but may require a search through all servers, which is problematic in terms of both search time and server load. It seems that a sensible solution is to use replicated databases, where each administrative domain keeps a copy of the database of servers pro- viding a particular service, and the attributes which characterize them. Each replicated database can either be flat or hierarchical. However, since it is local to the administrative domain, the load is much smaller than on a single worldwide database, and the time required to search the database is vastly reduced since its components are local. Replication even within an administrative domain can further reduce the loading bur- den, if needed. The main difficulty with replicated databases is population of the entries. However, multicast provides a natural framework for populating these databases. It allows servers to register with each database with- out them needing to know the address of each database (thus meeting the universality requirements and maintaining the simplicity of administra- tion present in SLP), and it is much more efficient than unicasting database entries from the servers to the databases, which causes the traffic volume to grow as the product of the number of databases and servers. Furthermore, techniques like those used in SAP [7] and RTCP [8] [9] [10] can be used to allow for scalability of the multicast adver- tisements. The Service Location Protocol provides a natural way in which to define this replicated database structure. It already provides the location service within an administrative domain, and the message formats and operations for clients, databases, and servers as defined are largely applicable. SLP also does not require SA's or UA's to have preconfigured information about infrastructure, which makes it more scalable and man- ageable. Furthermore, having different architectures for discovery of local and remote services is complex and unwieldy. Our extensions do not alter the interface seen by user agents, thus preserving the appearance of a unified mechanism for location of services. It is for this reason Rosenberg et al. November 20, 1997 [Page 3] Internet Draft Wide Area Location Nov. 14, 1997 we belive SLP with multicast extensions for wide area service location is a solution to the problem. This document specifies extensions to SLP which allow for servers scat- tered across the wide area network to register with DA's in various domains. It makes heavy use of scalable wide area multicast, and devel- ops new entities for improving scalability. It is not meant as a replacement for SLP, but rather as an extension to SLP which co-exists peacefully with existing systems. 3 Overview 3.1 Terms For clarity, we first define some terms in addition to those speci- fied in [1]: oService Location Protocol Domain (SLPD). An SLPD is a collection of UA's, SA's, and DA's under the administration of a single authority. DA's within one SLPD provide service only to those UA's within the SLPD. SA's within one SLPD may register their services using RFC2165 mechanisms only to DA's within their SLPD. oAdvertising Agent (AA). An advertising agent is responsible for advertising information about services within an SLPD. An SA, DA, or BA may act as an AA for some subset of the services it knows about. oBrokering Agent (BA). A brokering agent collects advertisements learned from AA's in remote SLPD's. A BA is much like a DA, except that it may not collect information about all service types. In a sense, a BA provides brokering services for a specific set of ser- vice types that it knows about. Such a device is useful since the scope and range of services on a wide area network can be large. To reduce storage requirements, and allow for optimized processing and software, a BA only worries about one (or several) service types. 3.2 Basic Operation The multicast extensions allow for both wide area service discovery, and multicast based registrations within an SLPD. Within a domain, multicast can be used to allow SA's to register themselves with SA's and/or DA's. Multicast within an SLPD further enhances its scalability for very large domains (like aol.com), where there may be a multitude of DA's, each of which shares the load from various SA's. Rosenberg et al. November 20, 1997 [Page 4] Internet Draft Wide Area Location Nov. 14, 1997 The operation of the multicast registration within an SLPD is simple. The domain is configured with a single, well-known, administratively scoped multicast group that is used for multicast registrations. Call this the registration group. Note that this group address is differ- ent from the ones currently used in SLP to discover services and send out DAAdverts. A multicast capable (that is, version 3) DA listens to this group, and multicast capable SA's send to the group. Optionally, BA's can listen to the group as well. In order to simplify configura- tion, SA's can readily determine whether there is a multicast capable DA or BA in the SLPD, since these devices will advertise their pres- ence using multicast to the registration group (A version 2 DA will send its DAAdverts to the DA discovery multicast address, which is different). If there are no such devices present, the SA will unicast its registration to the DA. When there are a mix of unicast and mul- ticast capable DA's, the SA will unicast its registrations to those non-multicast capable DA's, and multicast the registration as well. This allows an administrator to gradually upgrade an SLPD from uni- cast only operation to multicast without complex administration or configuration. The same mechanisms are used for Deregistration. Some subset of the services available within the SLPD can be adver- tised onto the wide area network to other SLPD's. This advertisement is accomplished by means of an advertising agent (AA). An SA, DA, or BA within an SLPD can be configured to act as an AA. When the AA is co-resident with the SA, it must be explicitly configured with the set of services known by the SA to advertise. When the AA is coresi- dent with a BA or DA, protected scopes are used to determine which services are to be advertised externally. An administrator assigns an SA to a protected scope if it wishes its service to be advertised externally. An AA is given the private keys for the protected scope, and will advertise any services it learns through protected scopes. This maintains the decentralized model of service configuration, yet allows for administrative controls over which services are adver- tised. The AA's then advertise these services onto a wide area multicast group. The AA's must also join the multicast group that they adver- tise into. This allows them to count the number of other AA's which are advertising, and then scale the rate of their advertisements pro- portionally in order to control multicast bandwidth usage. Note that the entire network between AA's and BA's need not be multicast. Tun- nels can be used to bring multicast to an AA or BA which needs it. This allows an SLPD who has a unicast-only ISP to still use multi- cast, since the tunnel is unicast as far as the ISP is concerned. As an alternative, the AA could act as an SA, and unicast its service registrations to another AA in a remote SLPD (which it has been authorized to do). That remote AA can then advertise on behalf of the unicast-only AA. Rosenberg et al. November 20, 1997 [Page 5] Internet Draft Wide Area Location Nov. 14, 1997 The BA's within an SLPD join the wide area multicast group corre- sponding to the service types they wish to broker for. As a result, they will build up a service database of services located in remote SLPD's. An SLPD may have multiple brokers for a particular service type. Furthermore, these brokers may not retain all of the advertise- ments they receive, dependent on some local policy or policing opera- tions. BA's also generate service advertisements that they send to the DA's within their SLPD. To do this, the BA acts as an SA. The service type it provides is the abstract type broker, and the concrete type is the one corresponding to the service type they are brokering. The service advertisement contains the service attributes of the brokering ser- vices that are provided. The BA, acting as an SA, can register itself with the DA using the unicast mechanisms of RFC2165, or the multicast approaches described here. In this fashion, the DA's within an SLPD know about all of the brokers within the SLPD. The DA's can use this information to decide which BA to contact in order to resolve a query from a UA. Based on this description, a client can locate a service as follows. Using current SLP methods, the client locates a DA in its domain. It sends out a request for a particular service to the DA. The DA may be able to resolve the query. This may be possible if the required ser- vice is within the domain. Otherwise, the DA cannot resolve the ser- vice request. However, a DA will always know about the BA's in each SLPD, and know which service types they are providing broker service for. The DA can then contact the BA directly with the query, and then forward the resolution back to the client. In this fashion, client behavior is unchanged between SLPv2 and SLPv3. Clients may also obtain information about BA's in remote SLPD's through some out of band means, such as an advertisement on a web page, and then contact them directly with queries. This would allow for competitive broker services (for example, a BA with the largest collection of service announcements from a media servers, with the fastest search engines, could offer its services to UA's outside its SLPD, and possibly charge for the brokering services provided). 4 BA URL's and Attributes Broker agents are both repositories for service information, and ser- vice providers themselves. Since they listen to particular multicast groups to build up a service database for particular service types, BA's can be considered as providing broker services for those partic- ular service types. Consider a BA which collects service advertisements about the service Rosenberg et al. November 20, 1997 [Page 6] Internet Draft Wide Area Location Nov. 14, 1997 type remote-fax. This BA can then be considered as providing broker services for remote-fax; the BA can direct users to the right remote-fax based on the attributes of the request. Since this broker- ing is a service itself, it can be described by a service URL as well. If a broker provides brokering for some service , then the URL for the broker service is [11]: ``service:broker:'' ``://'' Where the is the address of the broker. Furthermore, like other services, the broker service is characterized by attributes. These attributes are always a superset of the attributes which characterize the service being brokered. When a bro- ker has a particular attribute and value pair which are also a valid attribute value pair for the service, it means that the broker col- lects service registrations from servers which have that value for the attribute. For example, consider the following service template for the service type remote-fax: type=remote-fax version=0.0 lang=en description= The remote-fax service allows you to send a fax from a PC to a regular fax machine. url-syntax= url-path=; file-format= string M X tiff #File formats understood by fax gateway tiff,gif,postscript,eps payment-method= string M O #Payment methods accepted ecash,visa,mastercard,amex,discover,att-account Rosenberg et al. November 20, 1997 [Page 7] Internet Draft Wide Area Location Nov. 14, 1997 The concrete service template for the remote-fax broker might then look like: type=service:broker:remote-fax version=0.0 lang=en description= The remote-fax broker service allows you to find remote faxes, which allow you to send a fax from a PC to a regular fax machine. url-syntax= url-path=; file-format= string O M #File formats understood by fax gateway tiff,gif,postscript,eps payment-method= string O M #Payment methods accepted by remote fax ecash,visa,mastercard,amex,discover,att-account database-size= integer M #Size of broker's database - helpful in trying to resolve which broker to use broker-fee= string M X free #What is the charging model for this broker free,not-free According to these templates, the remote-fax service type has the attributes file-format and payment-method. The broker:remote-fax ser- vice type has the same attributes, plus two more (database-size and broker-fee) which help in choosing the broker. 5 Message Formats SLPv3 defines no new messages or message syntax beyond what is described in SLPv2 [2]. However, some of the fields have a slightly different semantic. The differences are: Rosenberg et al. November 20, 1997 [Page 8] Internet Draft Wide Area Location Nov. 14, 1997 oVersion This protocol document defines version 3 of the Service Location protocol. All multicast registrations from SA's, and advertisements from AA's should have the version number set to 3. oBitfields. These have the same definition as in SLPv2. For multi- cast registrations and AA advertisements, the multicast bit is set. The overflow bit may not be sent since all multicast regis- trations are UDP. oXID. The XID field is used to distinguish updated registrations from unchanged registrations. A registration message is considered unchanged if the attributes contained within are the same as the ones in a registration which was previously sent. The XID field is set to 0 for the first registration for a particular service URL. If the service attributes for that URL are unchanged the next time the registration is sent, the XID field is not incremented, else it is incremented by 1. This field helps BA's and DA's to decide whether or not to process a message depending on whether they have seen it or not. 6 SA Behavior Service Agents can operate in one of three modes: oUnicast registration - registrations are unicast to the DA('s) using only those mechanisms described in SLPv2. This happens when all DA's in the SLPD are v2, or the SA is v2. oMulticast registration - registrations are multicast to the regis- tration group. This happens when the SA is v3, and ALL DA's are v3. oHybrid registration - registrations are unicast and multicast. This happens when there is a mix of v3 and v2 DA's, and the SA is v3. To determine which mode to operate in, the SA listens to the registra- tion group. If, after WAIT_TIMER seconds after joining this group, the SA does not receive any DAAdvert messages or Multicast Service Registra- tions from a BA which is brokering for the service type provided by the SA, the SA decides to operate in unicast mode. In unicast registration mode, the SA registers its services using the unicast mechanisms described in SLPv2. The SLPv2 mechanisms will provide the SA with a list of DA's, which we call the unicast DA set, to which it must register. However, the SA continues to listen to the registra- tion group. If, at any time, the SA receives a DAAdvert message or Mul- ticast Service Registration from a relevant broker, it must switch modes Rosenberg et al. November 20, 1997 [Page 9] Internet Draft Wide Area Location Nov. 14, 1997 to hybrid. If, when listening to the multicast address, the SA receives either a DAAdvert or Multicast ServiceReg message from a relevant broker, it switches to hybrid mode. In this mode, the SA begins to multicast its service registrations, based on the rules described in Section 10. The SA also builds up a list of DAAdverts received from the registration group. The set of DA's which are learned through multicast is called the multicast DA set. This set is dynamic. Any DA which has not sent a DAAd- vert for more than five times the current transmission interval (this interval is the period between messages from an entity (BA,SA or DA) to the registration group; see section 10) is removed from the set. The SA continues to unicast its registrations to any DA which is in the unicast DA set and not in the multicast DA set. The SA also maintains a partial list of brokers. This list contains those brokers which provide broker service for a service type advertised by the SA. Any broker which has not sent a Multicast ServiceRegistration message for five times the cur- rent transmission interval is removed from the list. If, at any time, the multicast DA set becomes a superset of the unicast set, the SA switches to multicast mode. Furthermore, if the multicast DA set and broker list should become empty, the SA reverts to unicast reg- istration mode. In multicast registration mode, the SA registers its services using the multicast mechanisms described here. In this mode, all services sup- ported by an SA are registered using multicast. If the multicast DA set should ever cease being a superset of the unicast DA set, the SA reverts to hybrid mode. These basic rules allow an SLPD to be gradually upgraded from unicast only operation to multicast operation with no configuration. Of course, an administrator can force an SA to always unicast its registrations to some set of DA's if desired, even though the DA's may be multicast capa- ble. 7 DA Behavior The behavior of a DA is nearly identical to that of SLPv2, with three major differences. The first is that a DA may need to contact a BA to resolve the request. Secondly, a DA must listen to the registration group to collect advertisements, and third, a DA must multicast its DAAdvert messages on the registration group AS WELL as the DA discov- ery group defined in SLPv2. 7.1 Multicast Listening Both BA's and SA's may use multicast to register themselves with the Rosenberg et al. November 20, 1997 [Page 10] Internet Draft Wide Area Location Nov. 14, 1997 DA. It is therefore neccesary for the DA to listen to the registra- tion group used within the SLPD. By joining this group, the DA will receive multicast service registrations from BA's and SA's. A DA must keep all service registrations received from brokers. A DA may drop registrations received from SA's, but only if the DA knows of a BA in the SLPD which is providing broker services for that SA. Otherwise, the DA must keep all service registrations received from SA's (unless forbidden by some special administrative policy). This allows a DA to cease storing registrations from SA's as soon as there is a BA which is storing them. Since the DA always knows about BA's, the DA will still be able to satisfy client queries for local services by contacting the BA. 7.2 Contacting BA's In SLPv2, it is generally assumed that a DA knows about all services (at least within its scope). However, in SLPv3, there are many rea- sons why a DA will not know about a service: oThe service is local to the SLPD. However, the SLPD is using the multicast mechanisms for registering some of the SA's. This means that there are BA's within the SLPD, and that the DA may therefore not store all service registrations it receives. oThe service is not local to the SLPD, and the BA's are not coresi- dent with the DA. This means that information collected via multi- cast advertisements from remote SLPD's are not known to the DA. Even though a DA may not know about a service, it will always know about the BA's within the SLPD which broker for that service type. This is because all brokers must register themselves with all DA's. This regis- tration describes the service types which are being brokered (via the URL), and the characteristics of that brokering service. These attributes describe, among other things, the subset of the services which are brokered (for example, only those SA's providing remote-fax service with FILE-TYPE of TIFF). In that case, the URL path of all service:broker URL's should include the predicate describing the restriction. For example, the aforementioned remote-fax broker would have a service URL: service:broker:remote-fax://broker3.brokersrus.com/FILE-TYPE=TIFF When a DA gets a service request which it cannot resolve, since it doesn't know about the service at all, or one which it can resolve, but Rosenberg et al. November 20, 1997 [Page 11] Internet Draft Wide Area Location Nov. 14, 1997 for which it has only partial information (since there are brokers in the SLPD for that service), the DA should consult a broker. To determine which brokers to consult, the DA eliminates those brokers which do not broker for the service type and service which was requested. Such an elimination can happen if the service type is not brokered, or because the service type is brokered, but the attributes of the broker indicate that it does not broker for that particular service. The resulting set of brokers can potentially resolve the request. The DA then further fil- ters the list based on any local policy (for example, do not consult brokers which require payment for their services). The DA then acts as a UA, and sends a ServiceRequest message to each broker. It may send a message to each broker in parallel, or in series. Each BA will answer the request with a ServiceReply, containing a list of URL's for servers which match the query requirements. The DA may then send an AttributeRequest message to each SA to obtain additional attribute information which may be required to resolve the original request. The DA should not cache the resulting URL's and attribute information. The final match is then determined, and a list of URL's is returned to the UA in a ServiceReply message. Consider the following example. A UA formulates a query as follows: (&(service-type=media-server) (movie = eraser) (cost<=*)) This query is then sent to the DA. The DA doesn't know about the media- server service, but it knows about two BA's in the SLPD providing the media-server-broker service. It then sends the query to each of the two servers. Both respond with one URL matching the query (presumably the cheapest media server each knows about; this should be the same, but may not be since there are no enforced database synchronization rules). How- ever, if the URL's are different, the DA must determine which is actu- ally cheapest. To that end, it sends an AttributeRequest message to each SA containing the URL for the service. This yields a set of attribute value pairs, including cost. The DA then selects the cheapest of the two, and returns the resulting URL to the UA. In order to improve scalability, the DA must not query the SA's with an AttributeRequest, as above, unless the UA request contains either the <=* or >=* operator on an attribute. If the original request does not contain the MIN or MAX operator, the DA may return the entire list of URL's obtained from the BA's, or it may return some subset as it sees fit. Rosenberg et al. November 20, 1997 [Page 12] Internet Draft Wide Area Location Nov. 14, 1997 7.3 Multicasting DAAdverts As in SLPv2, the DA's will multicast DAAdverts to make themselves known. However, in SLPv3, DA's will also multicast DAAdverts to the registration group. This effectively announces its ability to receive multicast registrations. The rules for how to transmit the DAAdvert into this group are described in section 10. 8 AA Behavior An Advertising Agent (AA), is responsible for advertising attributes about the services within its SLPD to other SLPD's. An SA, DA or BA may act as an AA for some subset of services which it knows about. When the SA is acting as an AA, it is administratively configured with the set of services to advertise. Other services which the SA administrator would like to have advertised, but not by the SA itself, should be registered to the DA (and possibly BA) with a pro- tected scope. When the BA or DA is acting as an AA, they advertise those services in protected scopes with which they have been provided private keys. AA's send Multicast Service Registration messages to a wide-area mul- ticast group (called an advertising group). The rules for choosing the address of this group, and for when to send to the group, are described below. 9 BA Behavior A BA is responsible for collecting multicast advertisements heard about a particular service. 9.1 Receiving Advertisements A BA is administratively configured to broker for some set of service types, S. To do this, it determines the multicast groups to listen to for each service in S (see the section below on multicast group selection), and then joins them. This will cause the BA to receive advertisements. Since the groups are sometimes determined from hash functions, two services may both share a multicast group. The BA must drop all service registrations received on a multicast group for which it is not brokering. 9.2 Policy Once the BA has received a registration for a service that it is bro- kering, it still has the option of dropping this registration. It is within the rights of an administrator to configure a BA to drop advertisements based on any criteria which can be programmed into the Rosenberg et al. November 20, 1997 [Page 13] Internet Draft Wide Area Location Nov. 14, 1997 BA. This allows administrators to implement policy, in much the same way BGP policies allow routers to choose which routes to accept. Some examples of policies include: 1. The BA may drop all registrations received from a set of IP addresses. 2. The BA may drop all registrations which have an attribute set to a particular value. 3. The BA may drop all registrations which do not contain authen- tication blocks for the URL's. 4. The BA may only accept registrations with the attribute PAYMENT-METHOD set to CREDIT-CARD. 5. The BA may only hold the most recently received 100 registra- tions. This list is not meant to be at all exhaustive; it is only to illustrate that there is a wide range of possible policies, limited only by the imagination of the administrator. Note that these policies apply to services learned about from the wide area multicast group. Services learned from the registration group inside an SLPD should not be dropped. 9.3 Policing An optional mode of operation for a BA is policing. In this mode, the BA will discard advertisements from AA's who are sending messages faster than is allowed by the protocol operation described below. This will hopefully deter AA's from flooding advertisements to wide area group, which is a form of a denial of service attack. For each distinct AA which sends an advertisement, each BA will main- tain a few pieces of information. This information includes the last time an advertisement was received from that AA, and a violation counter, which is initialized at zero. At all points in time, BA's maintain the current minimum transmission interval (described below), which reflects the smallest allowed interval between transmission of a packet from any AA. When a packet is received from an AA, the BA computes the difference between the current time, and the last time an advertisement was received from that AA. If the difference is less than the minimum tranmsission interval, the counter is incremented. In either case, the value for the last time an advertisement was received is updated to the current time. Rosenberg et al. November 20, 1997 [Page 14] Internet Draft Wide Area Location Nov. 14, 1997 If the violation counter hits three, the BA should discard any fur- ther advertisements from this AA. The BA may eventually reset the counter, and begin accepting advertisements again, after some suit- ably long interval, at the discretion of the administrator. 10 Sending Multicast Advertisements Both within an SLPD, and across the wide area network, entitites will periodically transmit multicast packets. This section discusses the rules by which these packets are sent. 10.1 Scheduling Transmission of Advertisements The transmitting entity is assumed to have some set of packets, S, which it wishes to send to a multicast group. This situation arises when: oAn SA within an SLPD wishes to multicast its service registrtions to the registration group. oA DA within an SLPD wishes to multicast its DAAdverts to the reg- istration group. oA BA within an SLPD wishes to multicast its service registrations to the registration group. oAn AA wishes to multicast some of its services to the wide area network. The rules for transmission in all of these cases are identical: oAn entity wishing to send to some multicast group must be a member of the group. Call the time it first joins the group time t0. oThere must be only one entity sending to a particular multicast group per IP address. This allows the IP address to be used as a unique identifier for that entity. A multi-homed host should choose one interface for sending its messages. oAfter joining the group, the entity must continually maintain a list of all of the souce IP addresses seen in packets sent to the group. At any point in time, this list is used to determine the group size estimate, N, which is a count of the number of other entities transmitting to the group. This estimate is most easily obtained by counting the number of IP addresses seen. If storage is limited, the entity may use statistical sampling to reduce the size of the list, and obtain a statistical estimate of the group size estimate. Rosenberg et al. November 20, 1997 [Page 15] Internet Draft Wide Area Location Nov. 14, 1997 oA fixed amount of bandwidth, B, is assumed to be available for packet transmissions to the multicast group. By default, B is 8 kbps. In this way, if there are 1000 entities sending to the group, the period between messages from an entity is around 25 minutes on average. For ten-thousand entities it is a little over four hours. oThe entity selects an element (message) from S for transmission. If this element differs from the information in the element last time it was transmitted, the XID of the message is incremented, and the age of the message is set to zero. If the element is not different, the age of the element is incremented. oLet lt represent the last time any message from the entity was transmitted. The time of transmission for the next message, tn, is set to: tn = lt + R(1/2) max(CONFIG_FAST_TIMER * 2^(min(16,age)), N * K / B) R(1/2) is a random number uniformly distributed between 1/2 and 3/2. K is the size of the message in bits. CONFIG_FAST_TIMER is 1 second. This formula ensures that the total transmission rate of packets to the multicast group never exceeds B, by evenly dividing this rate among all of the N senders in the group. Furthermore, when group sizes are small, the packet rate is limited depending on the age of the message. A new message is transmitted with a small period, and the period increases as the age of the message grows. Eventually, the period increases to about once a day. oWhen time tn arrives, the entity does not send the packet. It recomputes the above formula, yeilding a new time, tn'. If tn' is less than tn, the packet is transmitted, lt is set to tn, and the entity selects another message to transmit, computes its transmis- sion time tn as above, and the process repeats. If tn' is more than tn, transmission of the message is further delayed until time tn. This algorithm, called reconsideration, helps avoid bursts of packets from entities who join the group initially, and then have a lowball estimate of the group size. 10.2 Timing Out Senders In addition to maintaining a list of IP addresses of senders to the group, each entity also maintains the last time a packet was received from that sender. Furthermore, each entity maintains a timeout inter- val, To, which is equal to: Rosenberg et al. November 20, 1997 [Page 16] Internet Draft Wide Area Location Nov. 14, 1997 To = 5 * max(CONFIG_FAST_TIMER * 65536, N * K' / B) Where K' is the MTU for the interface the entity is connected to. Any entity whose last transmission time is earlier than the current time minus To is assumed to no longer be active, and is therefore timed out. Its address is removed from the list of senders, and the group size estimate is decremented by 1. An entity which sends a Mulicast Deregistration is also removed from the list, and the group size is decremented by 1. 10.3 Minimum Transmission Interval For the policing operation, each entity may maintain an estimate of the minimum transmission interval, which is: Tmin = 1/2 max(CONFIG_INTERVAL_13, N * 128 / B) Where 128 is chosen as the minimum size in bits for an SLP packet. 10.4 Multicast Groups There are two different cases for choosing the multicast group to send to. In the first case, the entity is an SA, DA, or BA, advertis- ing its availability within in SLPD. In this case, all messages go on a single multicast group, called the registration group. This group must be administratively scoped. It may be a well-known group, whose value is to be determined by IANA. Administrators may also configure the system for usage with any other group, so long as it is adminis- tratively scoped. For AA's, advertisements are sent to wide area multicast groups. Each service is mapped to at least one multicast group. This multicast group is obtained by applying a hash function to the string which describes the service type (remote-fax, for example). The resulting value indicates an index of a multicast group to use. The set of mul- ticast groups at each index are to be determined by IANA. As an alternative, a single, well known, wide area multicast group can be used to advertise the addresses for particular services. When a new server comes up to offer a service, it first listens to this group. If it does not see any information about its own service, it obtains a multicast address, and then begins to send an advertisement Rosenberg et al. November 20, 1997 [Page 17] Internet Draft Wide Area Location Nov. 14, 1997 out indicating that this multicast address is to be used for the par- ticular service. This avoids static allocation of multicast addresses, which results in a waste of address space when there are too few services, and may result in large amounts of hash collisions when there are many services. Furthermore, AA's may also advertise onto private multicast addresses. This is useful when a set of SLPD's wish to share informa- tion about services, but only among themselves. 11 Open Issues There are many open issues remaining to be resolved. Some of the more important ones include: 1. Since multicast is used for service registrations, UDP must be used. This means that all registrations must fit within the path MTU. However, it is very likely that wide area services (like a media server), may have very large service descrip- tions. Some kind of mechanism for breaking up these advertise- ments into multiple packets seems necessary. Use of IP frag- mentation does not seem attractive. Rather, the AA should probably break its attributes into non-overlapping sets, and send sets of attributes in each packet. The precise mechanism for doing this remains unsolved. 2. The determination of multicast groups can be done in one of two ways - either using the hash based approach of SLPv2, or using an additional multicast group to advertise the bindings. Which one to use is an open issue. The latter seems more scal- able, but is more complex. 3. For certain services, should we allow for multiple multicast groups? The advertisements can be partitioned among the groups based on attributes. This would allow, for example, remote- faxes in Europe to advertise on one address, and remote-faxes in Africa to advertise on another. This allows a BA which isn't interested in all servers for a service to collect only those it wants by joining the appropriate multicast group. This makes the service to address binding problem harder, and further complicates the protocol, but may improve network bandwidth usage. 4. Wide area multicast is not generally available yet. In the interim, application level multicast, like that used in irc, can be used to connect regions of network level multicast. This would help improve the immediate applicability of the protocol, but at the expense of much complication. Bridging Rosenberg et al. November 20, 1997 [Page 18] Internet Draft Wide Area Location Nov. 14, 1997 application and network level multicast makes loop detection and duplicate packet generation a big problem. Solving them will largely require a re-invention of existing multicast routing protocols at the application layer. Is it necessary? 5. Obtaining certificates is a big issue for wide area services. Should we require wide area multicast registrations to contain SLP or X.509 certificates? Should they contain a URL which points to the certificate? The latter seems the most sensible solution. 6. Should we allow a DA to send referrals to BA's back to a UA? This is easily accomplished by having the service reply mes- sage contain a list of URL's for BA's instead of SA's. How- ever, it requires UA behavior to be modified, whereas the UA behavior is unchanged in these extensions. 7. When a BA boots, it will initially have an empty database. It can build up its database by listening to the group for long enough. However, for a group with many servers, the learning time may be substantial. Should we allow a BA to query another BA via unicast, and download the entire database for initial- ization? What happens if the policies in the two BA's are dif- ferent, so that the source rejected entries that the receiver would otherwise keep? 12 Acknowledgements The authors would like to thank Erik Guttman for his detailed and insightful comments on this work. 13 Bibliography [1] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, Service loca- tion protocol, Tech. Rep. RFC 2165, Internet Engineering Task Force, June 1997. [2] E. Guttman, C. Perkins, and J. Veizades, Service location proto- col, (internet draft), Internet Engineering Task Force, Oct. 1997. Work in Progress. [3] A. Gulbrandsen and P. Vixie, A DNS RR for specifying the location of services (DNS SRV), Tech. Rep. RFC 2052, Internet Engineering Task Force, Oct. 1996. [4] M. Hamilton, P. Leach, and R. Moats, Finding stuff (how to dis- cover services), Internet Draft, Internet Engineering Task Force, Rosenberg et al. November 20, 1997 [Page 19] Internet Draft Wide Area Location Nov. 14, 1997 Oct. 1997. Work in progress. [5] ITU-T, Recommendation X.500: The Directory: Overview of con- cepts, models, and services , Nov. 1993. [6] P. Deutsch, R. Schoultz, P. Faltstrom, and C. Weider, Architec- ture of the WHOIS++ service, Tech. Rep. RFC 1835, Internet Engineer- ing Task Force, Aug. 1995. [7] M. Handley, SAP: Session announcement protocol, Internet Draft, Internet Engineering Task Force, Nov. 1996. Work in progress. [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a transport protocol for real-time applications, Tech. Rep. RFC 1889, Internet Engineering Task Force, Jan. 1996. [9] J. Rosenberg and H. Schulzrinne, Timer reconsideration for enhanced RTP scalability, Internet Draft, Internet Engineering Task Force, July 1997. Work in progress. [10] J. Rosenberg and H. Schulzrinne, Timer reconsideration for enhanced rtp scalability, in To appear in Proceedings of IEEE Info- com '98 , 1998. [11] C. Perkins, E. Guttman, and J. Kempf, Schemes, Internet Draft, Internet Engineering Task Force, Oct. 1997. Work in progress. 14 Authors Addresses Jonathan Rosenberg Lucent Technologies, Bell Laboratories 101 Crawfords Corner Rd. Holmdel, NJ 07733 Rm. 4C-526 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. Rosenberg et al. November 20, 1997 [Page 20] Internet Draft Wide Area Location Nov. 14, 1997 Holmdel, NJ 07733 Rm. 4C-526 email: suter@bell-labs.com Rosenberg et al. November 20, 1997 [Page 21]