idnits 2.17.1 draft-ietf-svrloc-wasrv-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 883 looks like a reference -- Missing reference section? '2' on line 887 looks like a reference -- Missing reference section? '3' on line 891 looks like a reference -- Missing reference section? '4' on line 895 looks like a reference -- Missing reference section? '5' on line 899 looks like a reference -- Missing reference section? '6' on line 902 looks like a reference -- Missing reference section? '7' on line 906 looks like a reference -- Missing reference section? '8' on line 909 looks like a reference -- Missing reference section? '9' on line 913 looks like a reference -- Missing reference section? '10' on line 917 looks like a reference -- Missing reference section? '11' on line 921 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Service Location WG 3 Internet Draft J.Rosenberg,H.Schulzrinne,B.Suter 4 draft-ietf-svrloc-wasrv-01.txt Bell Laboratories 5 Nov. 14, 1997 6 Expires: May 1997 8 Wide Area Network Service Location 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 1 Abstract 32 We propose extensions to the Service Location Protocol (SLP), which 33 allow for registration and discovery of services scattered across the 34 wide area network. We make use of scalable wide area multicast to 35 allow agents within an administrative domain to learn about services 36 within other domains. We also describe a new agent, the Brokering 37 Agent (BA), which is responsible for providing information about a 38 particular set of services types. 40 2 Introduction and Motivation 42 The Service Location Protocol (SLP), recently approved as RFC 2165 43 [1], with version 2 under development [2], provides an automatic way 44 for clients to discover services within an administrative domain. 45 Clients can select services based on various attributes which 46 describe the service. The basic mechanism involves Service Agents 47 (SA)'s, which represent a service, registering their service 48 attributes with a Directory Agent (DA). User Agents (UA's) query the 49 DA with a set of desired attributes, and the DA replies with a set of 50 servers meeting the requirements. SLP also specifies operation when 51 there is no DA, by making use of multicast queries. 53 SLP is designed specifically for use within an administrative domain. 54 Its use of uncontrolled multicast for service queries and DA discov- 55 ery make it unscalable to wide area usage. However, there are many 56 cases where clients may wish to access services provided outside of 57 their administrative domain. This may be because the client's domain 58 does not provide the service, or because the servers inside the 59 domain do not meet the required criteria. Examples of such services 60 include media servers, telephony gateways, conference bridges, certi- 61 fication authorities, etc. 63 To facilitate the automatic discovery of such services, explicit pro- 64 tocol support is required. Such a protocol must meet a number of cri- 65 teria: 67 1. It must be scalable in terms of network usage; bandwidth con- 68 sumption in wide area accesses must be limited. 70 2. It must allow for multi-criteria selection. 72 3. It must allow a user to locate a service about which it has no 73 apriori hints for its location (such as the domain the service 74 is located in). This is key. If a client wishes to contact a 75 media server, it will not know that the media server is in 76 abc.com or nbc.com; it only cares that the server meets the 77 required service criteria. 79 4. It must be possible for an administrator to easily control the 80 set of services which can match a client request. This will 81 allow ISP's, for example, to filter services for its users, or 82 prevent its users from accessing certain services. 84 5. It must allow for universal service. In other words, the pro- 85 tocol should operate so that any host on the Internet can 86 potentially be a client for a service. Of course, local poli- 87 cies can restrict certain clients from accessing a service, 88 but it must be possible to provide universal service. 90 6. Locating a service should be fast. 92 7. It should be lightweight. 94 There are other methods which can be used to locate services in a wide 95 area network. These include the use of SRV records [3] [4], and other 96 approaches which leverage off of DNS, the world wide web, and large 97 distributed databases, such as X.500 [5] or whois++ [6]. The DNS based 98 approaches generally require the user to either know the domain in which 99 the service is located (which isn't generally known), or require the 100 service to be mapped into some hierarchy based on a single attribute 101 (therefore eliminating multi-criteria selection). The world wide web 102 allows users to search for services. However, the approaches used thus 103 far are not amenable to automation, and require significant human inter- 104 action to locate a service. Furthermore, they are generally based on 105 pull technologies, which means that services are often out of date. 106 Hierarchically distributed databases like X.500 have the same problem as 107 DNS - they require services to be mapped into a strict hierarchy, which 108 does not exist for multicriteria selection. Whois++, through centroids, 109 allows for non-hierarchically organized databases, but may require a 110 search through all servers, which is problematic in terms of both search 111 time and server load. 113 It seems that a sensible solution is to use replicated databases, where 114 each administrative domain keeps a copy of the database of servers pro- 115 viding a particular service, and the attributes which characterize them. 116 Each replicated database can either be flat or hierarchical. However, 117 since it is local to the administrative domain, the load is much smaller 118 than on a single worldwide database, and the time required to search the 119 database is vastly reduced since its components are local. Replication 120 even within an administrative domain can further reduce the loading bur- 121 den, if needed. 123 The main difficulty with replicated databases is population of the 124 entries. However, multicast provides a natural framework for populating 125 these databases. It allows servers to register with each database with- 126 out them needing to know the address of each database (thus meeting the 127 universality requirements and maintaining the simplicity of administra- 128 tion present in SLP), and it is much more efficient than unicasting 129 database entries from the servers to the databases, which causes the 130 traffic volume to grow as the product of the number of databases and 131 servers. Furthermore, techniques like those used in SAP [7] and RTCP [8] 132 [9] [10] can be used to allow for scalability of the multicast adver- 133 tisements. 135 The Service Location Protocol provides a natural way in which to define 136 this replicated database structure. It already provides the location 137 service within an administrative domain, and the message formats and 138 operations for clients, databases, and servers as defined are largely 139 applicable. SLP also does not require SA's or UA's to have preconfigured 140 information about infrastructure, which makes it more scalable and man- 141 ageable. Furthermore, having different architectures for discovery of 142 local and remote services is complex and unwieldy. Our extensions do not 143 alter the interface seen by user agents, thus preserving the appearance 144 of a unified mechanism for location of services. It is for this reason 145 we belive SLP with multicast extensions for wide area service location 146 is a solution to the problem. 148 This document specifies extensions to SLP which allow for servers scat- 149 tered across the wide area network to register with DA's in various 150 domains. It makes heavy use of scalable wide area multicast, and devel- 151 ops new entities for improving scalability. It is not meant as a 152 replacement for SLP, but rather as an extension to SLP which co-exists 153 peacefully with existing systems. 155 3 Overview 157 3.1 Terms 159 For clarity, we first define some terms in addition to those speci- 160 fied in [1]: 162 oService Location Protocol Domain (SLPD). An SLPD is a collection 163 of UA's, SA's, and DA's under the administration of a single 164 authority. DA's within one SLPD provide service only to those UA's 165 within the SLPD. SA's within one SLPD may register their services 166 using RFC2165 mechanisms only to DA's within their SLPD. 168 oAdvertising Agent (AA). An advertising agent is responsible for 169 advertising information about services within an SLPD. An SA, DA, 170 or BA may act as an AA for some subset of the services it knows 171 about. 173 oBrokering Agent (BA). A brokering agent collects advertisements 174 learned from AA's in remote SLPD's. A BA is much like a DA, except 175 that it may not collect information about all service types. In a 176 sense, a BA provides brokering services for a specific set of ser- 177 vice types that it knows about. Such a device is useful since the 178 scope and range of services on a wide area network can be large. 179 To reduce storage requirements, and allow for optimized processing 180 and software, a BA only worries about one (or several) service 181 types. 183 3.2 Basic Operation 185 The multicast extensions allow for both wide area service discovery, 186 and multicast based registrations within an SLPD. 188 Within a domain, multicast can be used to allow SA's to register 189 themselves with SA's and/or DA's. Multicast within an SLPD further 190 enhances its scalability for very large domains (like aol.com), where 191 there may be a multitude of DA's, each of which shares the load from 192 various SA's. 194 The operation of the multicast registration within an SLPD is simple. 195 The domain is configured with a single, well-known, administratively 196 scoped multicast group that is used for multicast registrations. Call 197 this the registration group. Note that this group address is differ- 198 ent from the ones currently used in SLP to discover services and send 199 out DAAdverts. A multicast capable (that is, version 3) DA listens to 200 this group, and multicast capable SA's send to the group. Optionally, 201 BA's can listen to the group as well. In order to simplify configura- 202 tion, SA's can readily determine whether there is a multicast capable 203 DA or BA in the SLPD, since these devices will advertise their pres- 204 ence using multicast to the registration group (A version 2 DA will 205 send its DAAdverts to the DA discovery multicast address, which is 206 different). If there are no such devices present, the SA will unicast 207 its registration to the DA. When there are a mix of unicast and mul- 208 ticast capable DA's, the SA will unicast its registrations to those 209 non-multicast capable DA's, and multicast the registration as well. 210 This allows an administrator to gradually upgrade an SLPD from uni- 211 cast only operation to multicast without complex administration or 212 configuration. The same mechanisms are used for Deregistration. 214 Some subset of the services available within the SLPD can be adver- 215 tised onto the wide area network to other SLPD's. This advertisement 216 is accomplished by means of an advertising agent (AA). An SA, DA, or 217 BA within an SLPD can be configured to act as an AA. When the AA is 218 co-resident with the SA, it must be explicitly configured with the 219 set of services known by the SA to advertise. When the AA is coresi- 220 dent with a BA or DA, protected scopes are used to determine which 221 services are to be advertised externally. An administrator assigns an 222 SA to a protected scope if it wishes its service to be advertised 223 externally. An AA is given the private keys for the protected scope, 224 and will advertise any services it learns through protected scopes. 225 This maintains the decentralized model of service configuration, yet 226 allows for administrative controls over which services are adver- 227 tised. 229 The AA's then advertise these services onto a wide area multicast 230 group. The AA's must also join the multicast group that they adver- 231 tise into. This allows them to count the number of other AA's which 232 are advertising, and then scale the rate of their advertisements pro- 233 portionally in order to control multicast bandwidth usage. Note that 234 the entire network between AA's and BA's need not be multicast. Tun- 235 nels can be used to bring multicast to an AA or BA which needs it. 236 This allows an SLPD who has a unicast-only ISP to still use multi- 237 cast, since the tunnel is unicast as far as the ISP is concerned. As 238 an alternative, the AA could act as an SA, and unicast its service 239 registrations to another AA in a remote SLPD (which it has been 240 authorized to do). That remote AA can then advertise on behalf of the 241 unicast-only AA. 243 The BA's within an SLPD join the wide area multicast group corre- 244 sponding to the service types they wish to broker for. As a result, 245 they will build up a service database of services located in remote 246 SLPD's. An SLPD may have multiple brokers for a particular service 247 type. Furthermore, these brokers may not retain all of the advertise- 248 ments they receive, dependent on some local policy or policing opera- 249 tions. 251 BA's also generate service advertisements that they send to the DA's 252 within their SLPD. To do this, the BA acts as an SA. The service type 253 it provides is the abstract type broker, and the concrete type is the 254 one corresponding to the service type they are brokering. The service 255 advertisement contains the service attributes of the brokering ser- 256 vices that are provided. The BA, acting as an SA, can register itself 257 with the DA using the unicast mechanisms of RFC2165, or the multicast 258 approaches described here. In this fashion, the DA's within an SLPD 259 know about all of the brokers within the SLPD. The DA's can use this 260 information to decide which BA to contact in order to resolve a query 261 from a UA. 263 Based on this description, a client can locate a service as follows. 264 Using current SLP methods, the client locates a DA in its domain. It 265 sends out a request for a particular service to the DA. The DA may be 266 able to resolve the query. This may be possible if the required ser- 267 vice is within the domain. Otherwise, the DA cannot resolve the ser- 268 vice request. However, a DA will always know about the BA's in each 269 SLPD, and know which service types they are providing broker service 270 for. The DA can then contact the BA directly with the query, and then 271 forward the resolution back to the client. In this fashion, client 272 behavior is unchanged between SLPv2 and SLPv3. 274 Clients may also obtain information about BA's in remote SLPD's 275 through some out of band means, such as an advertisement on a web 276 page, and then contact them directly with queries. This would allow 277 for competitive broker services (for example, a BA with the largest 278 collection of service announcements from a media servers, with the 279 fastest search engines, could offer its services to UA's outside its 280 SLPD, and possibly charge for the brokering services provided). 282 4 BA URL's and Attributes 284 Broker agents are both repositories for service information, and ser- 285 vice providers themselves. Since they listen to particular multicast 286 groups to build up a service database for particular service types, 287 BA's can be considered as providing broker services for those partic- 288 ular service types. 290 Consider a BA which collects service advertisements about the service 291 type remote-fax. This BA can then be considered as providing broker 292 services for remote-fax; the BA can direct users to the right 293 remote-fax based on the attributes of the request. Since this broker- 294 ing is a service itself, it can be described by a service URL as 295 well. If a broker provides brokering for some service , then 296 the URL for the broker service is [11]: 298 ``service:broker:'' ``://'' 300 Where the is the address of the broker. 302 Furthermore, like other services, the broker service is characterized 303 by attributes. These attributes are always a superset of the 304 attributes which characterize the service being brokered. When a bro- 305 ker has a particular attribute and value pair which are also a valid 306 attribute value pair for the service, it means that the broker col- 307 lects service registrations from servers which have that value for 308 the attribute. 310 For example, consider the following service template for the service 311 type remote-fax: 313 type=remote-fax 315 version=0.0 317 lang=en 319 description= 320 The remote-fax service allows you to send a fax from a PC to a regular 321 fax machine. 323 url-syntax= 324 url-path=; 326 file-format= string M X 327 tiff 328 #File formats understood by fax gateway 329 tiff,gif,postscript,eps 331 payment-method= string M O 332 #Payment methods accepted 333 ecash,visa,mastercard,amex,discover,att-account 334 The concrete service template for the remote-fax broker might then 335 look like: 337 type=service:broker:remote-fax 339 version=0.0 341 lang=en 343 description= 344 The remote-fax broker service allows you to find remote faxes, which 345 allow you to send a fax from a PC to a regular fax machine. 347 url-syntax= 348 url-path=; 350 file-format= string O M 351 #File formats understood by fax gateway 352 tiff,gif,postscript,eps 354 payment-method= string O M 355 #Payment methods accepted by remote fax 356 ecash,visa,mastercard,amex,discover,att-account 358 database-size= integer M 359 #Size of broker's database - helpful in trying to resolve which broker 360 to use 362 broker-fee= string M X 363 free 364 #What is the charging model for this broker 365 free,not-free 367 According to these templates, the remote-fax service type has the 368 attributes file-format and payment-method. The broker:remote-fax ser- 369 vice type has the same attributes, plus two more (database-size and 370 broker-fee) which help in choosing the broker. 372 5 Message Formats 374 SLPv3 defines no new messages or message syntax beyond what is 375 described in SLPv2 [2]. 377 However, some of the fields have a slightly different semantic. The 378 differences are: 380 oVersion This protocol document defines version 3 of the Service 381 Location protocol. All multicast registrations from SA's, and 382 advertisements from AA's should have the version number set to 3. 384 oBitfields. These have the same definition as in SLPv2. For multi- 385 cast registrations and AA advertisements, the multicast bit is 386 set. The overflow bit may not be sent since all multicast regis- 387 trations are UDP. 389 oXID. The XID field is used to distinguish updated registrations 390 from unchanged registrations. A registration message is considered 391 unchanged if the attributes contained within are the same as the 392 ones in a registration which was previously sent. The XID field is 393 set to 0 for the first registration for a particular service URL. 394 If the service attributes for that URL are unchanged the next time 395 the registration is sent, the XID field is not incremented, else 396 it is incremented by 1. This field helps BA's and DA's to decide 397 whether or not to process a message depending on whether they have 398 seen it or not. 400 6 SA Behavior 402 Service Agents can operate in one of three modes: 404 oUnicast registration - registrations are unicast to the DA('s) 405 using only those mechanisms described in SLPv2. This happens when 406 all DA's in the SLPD are v2, or the SA is v2. 408 oMulticast registration - registrations are multicast to the regis- 409 tration group. This happens when the SA is v3, and ALL DA's are 410 v3. 412 oHybrid registration - registrations are unicast and multicast. 413 This happens when there is a mix of v3 and v2 DA's, and the SA is 414 v3. 416 To determine which mode to operate in, the SA listens to the registra- 417 tion group. If, after WAIT_TIMER seconds after joining this group, the 418 SA does not receive any DAAdvert messages or Multicast Service Registra- 419 tions from a BA which is brokering for the service type provided by the 420 SA, the SA decides to operate in unicast mode. 422 In unicast registration mode, the SA registers its services using the 423 unicast mechanisms described in SLPv2. The SLPv2 mechanisms will provide 424 the SA with a list of DA's, which we call the unicast DA set, to which 425 it must register. However, the SA continues to listen to the registra- 426 tion group. If, at any time, the SA receives a DAAdvert message or Mul- 427 ticast Service Registration from a relevant broker, it must switch modes 428 to hybrid. 430 If, when listening to the multicast address, the SA receives either a 431 DAAdvert or Multicast ServiceReg message from a relevant broker, it 432 switches to hybrid mode. In this mode, the SA begins to multicast its 433 service registrations, based on the rules described in Section 10. The 434 SA also builds up a list of DAAdverts received from the registration 435 group. The set of DA's which are learned through multicast is called the 436 multicast DA set. This set is dynamic. Any DA which has not sent a DAAd- 437 vert for more than five times the current transmission interval (this 438 interval is the period between messages from an entity (BA,SA or DA) to 439 the registration group; see section 10) is removed from the set. The SA 440 continues to unicast its registrations to any DA which is in the unicast 441 DA set and not in the multicast DA set. The SA also maintains a partial 442 list of brokers. This list contains those brokers which provide broker 443 service for a service type advertised by the SA. Any broker which has 444 not sent a Multicast ServiceRegistration message for five times the cur- 445 rent transmission interval is removed from the list. 447 If, at any time, the multicast DA set becomes a superset of the unicast 448 set, the SA switches to multicast mode. Furthermore, if the multicast DA 449 set and broker list should become empty, the SA reverts to unicast reg- 450 istration mode. 452 In multicast registration mode, the SA registers its services using the 453 multicast mechanisms described here. In this mode, all services sup- 454 ported by an SA are registered using multicast. If the multicast DA set 455 should ever cease being a superset of the unicast DA set, the SA reverts 456 to hybrid mode. 458 These basic rules allow an SLPD to be gradually upgraded from unicast 459 only operation to multicast operation with no configuration. Of course, 460 an administrator can force an SA to always unicast its registrations to 461 some set of DA's if desired, even though the DA's may be multicast capa- 462 ble. 464 7 DA Behavior 466 The behavior of a DA is nearly identical to that of SLPv2, with three 467 major differences. The first is that a DA may need to contact a BA to 468 resolve the request. Secondly, a DA must listen to the registration 469 group to collect advertisements, and third, a DA must multicast its 470 DAAdvert messages on the registration group AS WELL as the DA discov- 471 ery group defined in SLPv2. 473 7.1 Multicast Listening 475 Both BA's and SA's may use multicast to register themselves with the 476 DA. It is therefore neccesary for the DA to listen to the registra- 477 tion group used within the SLPD. By joining this group, the DA will 478 receive multicast service registrations from BA's and SA's. 480 A DA must keep all service registrations received from brokers. A DA 481 may drop registrations received from SA's, but only if the DA knows 482 of a BA in the SLPD which is providing broker services for that SA. 483 Otherwise, the DA must keep all service registrations received from 484 SA's (unless forbidden by some special administrative policy). 486 This allows a DA to cease storing registrations from SA's as soon as 487 there is a BA which is storing them. Since the DA always knows about 488 BA's, the DA will still be able to satisfy client queries for local 489 services by contacting the BA. 491 7.2 Contacting BA's 493 In SLPv2, it is generally assumed that a DA knows about all services 494 (at least within its scope). However, in SLPv3, there are many rea- 495 sons why a DA will not know about a service: 497 oThe service is local to the SLPD. However, the SLPD is using the 498 multicast mechanisms for registering some of the SA's. This means 499 that there are BA's within the SLPD, and that the DA may therefore 500 not store all service registrations it receives. 502 oThe service is not local to the SLPD, and the BA's are not coresi- 503 dent with the DA. This means that information collected via multi- 504 cast advertisements from remote SLPD's are not known to the DA. 506 Even though a DA may not know about a service, it will always know about 507 the BA's within the SLPD which broker for that service type. This is 508 because all brokers must register themselves with all DA's. This regis- 509 tration describes the service types which are being brokered (via the 510 URL), and the characteristics of that brokering service. These 511 attributes describe, among other things, the subset of the services 512 which are brokered (for example, only those SA's providing remote-fax 513 service with FILE-TYPE of TIFF). In that case, the URL path of all 514 service:broker URL's should include the predicate describing the 515 restriction. For example, the aforementioned remote-fax broker would 516 have a service URL: 518 service:broker:remote-fax://broker3.brokersrus.com/FILE-TYPE=TIFF 520 When a DA gets a service request which it cannot resolve, since it 521 doesn't know about the service at all, or one which it can resolve, but 522 for which it has only partial information (since there are brokers in 523 the SLPD for that service), the DA should consult a broker. To determine 524 which brokers to consult, the DA eliminates those brokers which do not 525 broker for the service type and service which was requested. Such an 526 elimination can happen if the service type is not brokered, or because 527 the service type is brokered, but the attributes of the broker indicate 528 that it does not broker for that particular service. The resulting set 529 of brokers can potentially resolve the request. The DA then further fil- 530 ters the list based on any local policy (for example, do not consult 531 brokers which require payment for their services). 533 The DA then acts as a UA, and sends a ServiceRequest message to each 534 broker. It may send a message to each broker in parallel, or in series. 535 Each BA will answer the request with a ServiceReply, containing a list 536 of URL's for servers which match the query requirements. The DA may then 537 send an AttributeRequest message to each SA to obtain additional 538 attribute information which may be required to resolve the original 539 request. The DA should not cache the resulting URL's and attribute 540 information. The final match is then determined, and a list of URL's is 541 returned to the UA in a ServiceReply message. 543 Consider the following example. A UA formulates a query as follows: 545 (&(service-type=media-server) 546 (movie = eraser) 547 (cost<=*)) 549 This query is then sent to the DA. The DA doesn't know about the media- 550 server service, but it knows about two BA's in the SLPD providing the 551 media-server-broker service. It then sends the query to each of the two 552 servers. Both respond with one URL matching the query (presumably the 553 cheapest media server each knows about; this should be the same, but may 554 not be since there are no enforced database synchronization rules). How- 555 ever, if the URL's are different, the DA must determine which is actu- 556 ally cheapest. To that end, it sends an AttributeRequest message to each 557 SA containing the URL for the service. This yields a set of attribute 558 value pairs, including cost. The DA then selects the cheapest of the 559 two, and returns the resulting URL to the UA. 561 In order to improve scalability, the DA must not query the SA's with an 562 AttributeRequest, as above, unless the UA request contains either the 563 <=* or >=* operator on an attribute. If the original request does not 564 contain the MIN or MAX operator, the DA may return the entire list of 565 URL's obtained from the BA's, or it may return some subset as it sees 566 fit. 568 7.3 Multicasting DAAdverts 570 As in SLPv2, the DA's will multicast DAAdverts to make themselves 571 known. However, in SLPv3, DA's will also multicast DAAdverts to the 572 registration group. This effectively announces its ability to receive 573 multicast registrations. The rules for how to transmit the DAAdvert 574 into this group are described in section 10. 576 8 AA Behavior 578 An Advertising Agent (AA), is responsible for advertising attributes 579 about the services within its SLPD to other SLPD's. An SA, DA or BA 580 may act as an AA for some subset of services which it knows about. 581 When the SA is acting as an AA, it is administratively configured 582 with the set of services to advertise. Other services which the SA 583 administrator would like to have advertised, but not by the SA 584 itself, should be registered to the DA (and possibly BA) with a pro- 585 tected scope. When the BA or DA is acting as an AA, they advertise 586 those services in protected scopes with which they have been provided 587 private keys. 589 AA's send Multicast Service Registration messages to a wide-area mul- 590 ticast group (called an advertising group). The rules for choosing 591 the address of this group, and for when to send to the group, are 592 described below. 594 9 BA Behavior 596 A BA is responsible for collecting multicast advertisements heard 597 about a particular service. 599 9.1 Receiving Advertisements 601 A BA is administratively configured to broker for some set of service 602 types, S. To do this, it determines the multicast groups to listen to 603 for each service in S (see the section below on multicast group 604 selection), and then joins them. This will cause the BA to receive 605 advertisements. Since the groups are sometimes determined from hash 606 functions, two services may both share a multicast group. The BA must 607 drop all service registrations received on a multicast group for 608 which it is not brokering. 610 9.2 Policy 612 Once the BA has received a registration for a service that it is bro- 613 kering, it still has the option of dropping this registration. It is 614 within the rights of an administrator to configure a BA to drop 615 advertisements based on any criteria which can be programmed into the 616 BA. This allows administrators to implement policy, in much the same 617 way BGP policies allow routers to choose which routes to accept. Some 618 examples of policies include: 620 1. The BA may drop all registrations received from a set of IP 621 addresses. 623 2. The BA may drop all registrations which have an attribute set 624 to a particular value. 626 3. The BA may drop all registrations which do not contain authen- 627 tication blocks for the URL's. 629 4. The BA may only accept registrations with the attribute 630 PAYMENT-METHOD set to CREDIT-CARD. 632 5. The BA may only hold the most recently received 100 registra- 633 tions. 635 This list is not meant to be at all exhaustive; it is only to illustrate 636 that there is a wide range of possible policies, limited only by the 637 imagination of the administrator. 639 Note that these policies apply to services learned about from the wide 640 area multicast group. Services learned from the registration group 641 inside an SLPD should not be dropped. 643 9.3 Policing 645 An optional mode of operation for a BA is policing. In this mode, the 646 BA will discard advertisements from AA's who are sending messages 647 faster than is allowed by the protocol operation described below. 648 This will hopefully deter AA's from flooding advertisements to wide 649 area group, which is a form of a denial of service attack. 651 For each distinct AA which sends an advertisement, each BA will main- 652 tain a few pieces of information. This information includes the last 653 time an advertisement was received from that AA, and a violation 654 counter, which is initialized at zero. At all points in time, BA's 655 maintain the current minimum transmission interval (described below), 656 which reflects the smallest allowed interval between transmission of 657 a packet from any AA. When a packet is received from an AA, the BA 658 computes the difference between the current time, and the last time 659 an advertisement was received from that AA. If the difference is less 660 than the minimum tranmsission interval, the counter is incremented. 661 In either case, the value for the last time an advertisement was 662 received is updated to the current time. 664 If the violation counter hits three, the BA should discard any fur- 665 ther advertisements from this AA. The BA may eventually reset the 666 counter, and begin accepting advertisements again, after some suit- 667 ably long interval, at the discretion of the administrator. 669 10 Sending Multicast Advertisements 671 Both within an SLPD, and across the wide area network, entitites will 672 periodically transmit multicast packets. This section discusses the 673 rules by which these packets are sent. 675 10.1 Scheduling Transmission of Advertisements 677 The transmitting entity is assumed to have some set of packets, S, 678 which it wishes to send to a multicast group. This situation arises 679 when: 681 oAn SA within an SLPD wishes to multicast its service registrtions 682 to the registration group. 684 oA DA within an SLPD wishes to multicast its DAAdverts to the reg- 685 istration group. 687 oA BA within an SLPD wishes to multicast its service registrations 688 to the registration group. 690 oAn AA wishes to multicast some of its services to the wide area 691 network. 693 The rules for transmission in all of these cases are identical: 695 oAn entity wishing to send to some multicast group must be a member 696 of the group. Call the time it first joins the group time t0. 698 oThere must be only one entity sending to a particular multicast 699 group per IP address. This allows the IP address to be used as a 700 unique identifier for that entity. A multi-homed host should 701 choose one interface for sending its messages. 703 oAfter joining the group, the entity must continually maintain a 704 list of all of the souce IP addresses seen in packets sent to the 705 group. At any point in time, this list is used to determine the 706 group size estimate, N, which is a count of the number of other 707 entities transmitting to the group. This estimate is most easily 708 obtained by counting the number of IP addresses seen. If storage 709 is limited, the entity may use statistical sampling to reduce the 710 size of the list, and obtain a statistical estimate of the group 711 size estimate. 713 oA fixed amount of bandwidth, B, is assumed to be available for 714 packet transmissions to the multicast group. By default, B is 8 715 kbps. In this way, if there are 1000 entities sending to the 716 group, the period between messages from an entity is around 25 717 minutes on average. For ten-thousand entities it is a little over 718 four hours. 720 oThe entity selects an element (message) from S for transmission. 721 If this element differs from the information in the element last 722 time it was transmitted, the XID of the message is incremented, 723 and the age of the message is set to zero. If the element is not 724 different, the age of the element is incremented. 726 oLet lt represent the last time any message from the entity was 727 transmitted. The time of transmission for the next message, tn, is 728 set to: 730 tn = lt + R(1/2) max(CONFIG_FAST_TIMER * 2^(min(16,age)), N * K / B) 732 R(1/2) is a random number uniformly distributed between 1/2 and 733 3/2. K is the size of the message in bits. CONFIG_FAST_TIMER is 1 734 second. This formula ensures that the total transmission rate of 735 packets to the multicast group never exceeds B, by evenly dividing 736 this rate among all of the N senders in the group. Furthermore, 737 when group sizes are small, the packet rate is limited depending on 738 the age of the message. A new message is transmitted with a small 739 period, and the period increases as the age of the message grows. 740 Eventually, the period increases to about once a day. 742 oWhen time tn arrives, the entity does not send the packet. It 743 recomputes the above formula, yeilding a new time, tn'. If tn' is 744 less than tn, the packet is transmitted, lt is set to tn, and the 745 entity selects another message to transmit, computes its transmis- 746 sion time tn as above, and the process repeats. If tn' is more 747 than tn, transmission of the message is further delayed until time 748 tn. This algorithm, called reconsideration, helps avoid bursts of 749 packets from entities who join the group initially, and then have 750 a lowball estimate of the group size. 752 10.2 Timing Out Senders 754 In addition to maintaining a list of IP addresses of senders to the 755 group, each entity also maintains the last time a packet was received 756 from that sender. Furthermore, each entity maintains a timeout inter- 757 val, To, which is equal to: 759 To = 5 * max(CONFIG_FAST_TIMER * 65536, N * K' / B) 761 Where K' is the MTU for the interface the entity is connected to. Any 762 entity whose last transmission time is earlier than the current time 763 minus To is assumed to no longer be active, and is therefore timed 764 out. Its address is removed from the list of senders, and the group 765 size estimate is decremented by 1. 767 An entity which sends a Mulicast Deregistration is also removed from 768 the list, and the group size is decremented by 1. 770 10.3 Minimum Transmission Interval 772 For the policing operation, each entity may maintain an estimate of 773 the minimum transmission interval, which is: 775 Tmin = 1/2 max(CONFIG_INTERVAL_13, N * 128 / B) 777 Where 128 is chosen as the minimum size in bits for an SLP packet. 779 10.4 Multicast Groups 781 There are two different cases for choosing the multicast group to 782 send to. In the first case, the entity is an SA, DA, or BA, advertis- 783 ing its availability within in SLPD. In this case, all messages go on 784 a single multicast group, called the registration group. This group 785 must be administratively scoped. It may be a well-known group, whose 786 value is to be determined by IANA. Administrators may also configure 787 the system for usage with any other group, so long as it is adminis- 788 tratively scoped. 790 For AA's, advertisements are sent to wide area multicast groups. Each 791 service is mapped to at least one multicast group. This multicast 792 group is obtained by applying a hash function to the string which 793 describes the service type (remote-fax, for example). The resulting 794 value indicates an index of a multicast group to use. The set of mul- 795 ticast groups at each index are to be determined by IANA. 797 As an alternative, a single, well known, wide area multicast group 798 can be used to advertise the addresses for particular services. When 799 a new server comes up to offer a service, it first listens to this 800 group. If it does not see any information about its own service, it 801 obtains a multicast address, and then begins to send an advertisement 802 out indicating that this multicast address is to be used for the par- 803 ticular service. This avoids static allocation of multicast 804 addresses, which results in a waste of address space when there are 805 too few services, and may result in large amounts of hash collisions 806 when there are many services. 808 Furthermore, AA's may also advertise onto private multicast 809 addresses. This is useful when a set of SLPD's wish to share informa- 810 tion about services, but only among themselves. 812 11 Open Issues 814 There are many open issues remaining to be resolved. Some of the more 815 important ones include: 817 1. Since multicast is used for service registrations, UDP must be 818 used. This means that all registrations must fit within the 819 path MTU. However, it is very likely that wide area services 820 (like a media server), may have very large service descrip- 821 tions. Some kind of mechanism for breaking up these advertise- 822 ments into multiple packets seems necessary. Use of IP frag- 823 mentation does not seem attractive. Rather, the AA should 824 probably break its attributes into non-overlapping sets, and 825 send sets of attributes in each packet. The precise mechanism 826 for doing this remains unsolved. 828 2. The determination of multicast groups can be done in one of 829 two ways - either using the hash based approach of SLPv2, or 830 using an additional multicast group to advertise the bindings. 831 Which one to use is an open issue. The latter seems more scal- 832 able, but is more complex. 834 3. For certain services, should we allow for multiple multicast 835 groups? The advertisements can be partitioned among the groups 836 based on attributes. This would allow, for example, remote- 837 faxes in Europe to advertise on one address, and remote-faxes 838 in Africa to advertise on another. This allows a BA which 839 isn't interested in all servers for a service to collect only 840 those it wants by joining the appropriate multicast group. 841 This makes the service to address binding problem harder, and 842 further complicates the protocol, but may improve network 843 bandwidth usage. 845 4. Wide area multicast is not generally available yet. In the 846 interim, application level multicast, like that used in irc, 847 can be used to connect regions of network level multicast. 848 This would help improve the immediate applicability of the 849 protocol, but at the expense of much complication. Bridging 850 application and network level multicast makes loop detection 851 and duplicate packet generation a big problem. Solving them 852 will largely require a re-invention of existing multicast 853 routing protocols at the application layer. Is it necessary? 855 5. Obtaining certificates is a big issue for wide area services. 856 Should we require wide area multicast registrations to contain 857 SLP or X.509 certificates? Should they contain a URL which 858 points to the certificate? The latter seems the most sensible 859 solution. 861 6. Should we allow a DA to send referrals to BA's back to a UA? 862 This is easily accomplished by having the service reply mes- 863 sage contain a list of URL's for BA's instead of SA's. How- 864 ever, it requires UA behavior to be modified, whereas the UA 865 behavior is unchanged in these extensions. 867 7. When a BA boots, it will initially have an empty database. It 868 can build up its database by listening to the group for long 869 enough. However, for a group with many servers, the learning 870 time may be substantial. Should we allow a BA to query another 871 BA via unicast, and download the entire database for initial- 872 ization? What happens if the policies in the two BA's are dif- 873 ferent, so that the source rejected entries that the receiver 874 would otherwise keep? 876 12 Acknowledgements 878 The authors would like to thank Erik Guttman for his detailed and 879 insightful comments on this work. 881 13 Bibliography 883 [1] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, Service loca- 884 tion protocol, Tech. Rep. RFC 2165, Internet Engineering Task Force, 885 June 1997. 887 [2] E. Guttman, C. Perkins, and J. Veizades, Service location proto- 888 col, (internet draft), Internet Engineering Task Force, Oct. 1997. 889 Work in Progress. 891 [3] A. Gulbrandsen and P. Vixie, A DNS RR for specifying the location 892 of services (DNS SRV), Tech. Rep. RFC 2052, Internet Engineering Task 893 Force, Oct. 1996. 895 [4] M. Hamilton, P. Leach, and R. Moats, Finding stuff (how to dis- 896 cover services), Internet Draft, Internet Engineering Task Force, 897 Oct. 1997. Work in progress. 899 [5] ITU-T, Recommendation X.500: The Directory: Overview of con- 900 cepts, models, and services , Nov. 1993. 902 [6] P. Deutsch, R. Schoultz, P. Faltstrom, and C. Weider, Architec- 903 ture of the WHOIS++ service, Tech. Rep. RFC 1835, Internet Engineer- 904 ing Task Force, Aug. 1995. 906 [7] M. Handley, SAP: Session announcement protocol, Internet Draft, 907 Internet Engineering Task Force, Nov. 1996. Work in progress. 909 [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a 910 transport protocol for real-time applications, Tech. Rep. RFC 1889, 911 Internet Engineering Task Force, Jan. 1996. 913 [9] J. Rosenberg and H. Schulzrinne, Timer reconsideration for 914 enhanced RTP scalability, Internet Draft, Internet Engineering Task 915 Force, July 1997. Work in progress. 917 [10] J. Rosenberg and H. Schulzrinne, Timer reconsideration for 918 enhanced rtp scalability, in To appear in Proceedings of IEEE Info- 919 com '98 , 1998. 921 [11] C. Perkins, E. Guttman, and J. Kempf, Schemes, Internet Draft, 922 Internet Engineering Task Force, Oct. 1997. Work in progress. 924 14 Authors Addresses 926 Jonathan Rosenberg 927 Lucent Technologies, Bell Laboratories 928 101 Crawfords Corner Rd. 929 Holmdel, NJ 07733 930 Rm. 4C-526 931 email: jdrosen@bell-labs.com 933 Henning Schulzrinne 934 Columbia University 935 M/S 0401 936 1214 Amsterdam Ave. 937 New York, NY 10027-7003 938 email: schulzrinne@cs.columbia.edu 940 Bernhard Suter 941 Lucent Technologies, Bell Laboratories 942 101 Crawfords Corner Rd. 944 Holmdel, NJ 07733 945 Rm. 4C-526 946 email: suter@bell-labs.com