[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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 <srvtype>, then
   the URL for the broker service is [11]:


   ``service:broker:'' <srvtype> ``://'' <addr-spec>


   Where the <addr-spec> 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]