idnits 2.17.1 draft-rosenberg-wasrv-arch-00.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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.) -- The document date (February 15, 1998) is 9565 days in the past. Is this intentional? 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 381 looks like a reference -- Missing reference section? '2' on line 385 looks like a reference -- Missing reference section? '3' on line 389 looks like a reference -- Missing reference section? '4' on line 392 looks like a reference -- Missing reference section? '5' on line 395 looks like a reference -- Missing reference section? '6' on line 399 looks like a reference -- Missing reference section? '7' on line 403 looks like a reference -- Missing reference section? '8' on line 407 looks like a reference -- Missing reference section? '9' on line 411 looks like a reference -- Missing reference section? '10' on line 415 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force WASRV 2 INTERNET DRAFT 3 Jonathan Rosenberg 4 Bell Laboratories 5 Erik Guttman 6 Sun Microsystems 7 Ryan Moats 8 AT&T 9 Henning Schulzrinne 10 draft-rosenberg-wasrv-arch-00.txt Columbia U. 11 February 15, 1998 12 Expires: August 15, 1998 14 WASRV Architectural Principles 16 STATUS OF THIS MEMO 18 This document is an Internet-Draft. Internet-Drafts are working docu- 19 ments of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute work- 21 ing documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference mate- 26 rial or to cite them other than as ``work in progress''. 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Distribution of this document is unlimited. 36 1 Abstract 38 This document defines the problem of wide area service location, 39 describing its key attributes, and giving examples of location prob- 40 lems which do or do not fall under its definition. It also touches 41 on a number of related protocols, and looks at how they fit, or do 42 not fit, the problem of wide area service location. 44 2 Introduction 46 There has been recent interest in mechanisms for discovery of ser- 47 vices across the global internet. Such interest has manifested itself 48 in numerous papers, standards proposals, and commercial tools. How- 49 ever, what is meant by wide area service location seems to vary in 50 all cases. This document defines the problem of wide area service 51 location explicitly and narrowly. It also looks at how some current 52 protocol architecures may or may not be applied to it. 54 3 Problem Definition 56 Wide Area Service Location would allow client software to find ser- 57 vices in remote locations in the Internet. Currently, this is very 58 difficult to do. It generally requires the client software to be con- 59 figured with the network address or domain name of a server. This 60 requires the end-user to have knowledge of the network rather than 61 merely an understanding of what she wishes to achieve. 63 Wide Area Service Location would enable the discovery of services 64 based on usage criteria as opposed to explicit knowledge of the name 65 or address of the server. The considerations included below express 66 the features which Wide Area Service Location should possess and 67 issues which it must confront. 69 oMulti-criteria. The client desires a service which can be charac- 70 terized by a number of attributes. The client should be able to 71 express the desired attributes of the service, and get back a 72 server whose service meets the criteria. There should be no arbi- 73 trary restriction on the type, values, or number of attributes 74 which can potentially characterize a service. Some restrictions on 75 typing and some convention with respect to the interpretation of 76 values will exist in any wide area service location protocol. 78 oLocation Independent. The location of the desired server is 79 irrelevent and may not be known a priori. That is, the domain 80 name, administrative domain and network address of the desired 81 service is not generally known in advance and in many cases is not 82 pertinent. In some cases, the location of a server may be impor- 83 tant, but no more important than any other attribute of the ser- 84 vice. 86 oAuto Configured. It should be straightfoward to configure new 87 clients and servers to use the Wide Area Service Location Proto- 88 col. The new service should automatically be discoverable, requir- 89 ing little or no setting of addresses or other parameters. 91 oRapid Availability. When a server is first brought on line, it 92 should become visible and accessible to clients rapidly. 94 oService Based. The attributes provided by the client provide the 95 attributes of the service, not the content provided by that ser- 96 vice. For example, an attribute for a web server might be support 97 of ICP, as this is a characteristic of the web service. Contains 98 web page X is not an attribute of a web server, but rather a 99 description of the content provided by a web server. 101 oAutomated. The service location process should be automated, and 102 not rely on interactive input from a user to satisfy a reasonable 103 query. However, the protocol should not prevent interactive ses- 104 sions. 106 oRapid. The service location process should occur as rapidly as 107 possible. Usually, it is the precursor to further communciations 108 between the client and the server. Service discovery adds to the 109 amount of time required to actually access the service. 111 oPolicy Support. The agent responsible for satisfying the client's 112 service request should be able to inject its own policy into the 113 process. This policy may disallow various servers from being used 114 by the particular client, for example. 116 oWorldwide. The location of a matching server can be anywhere, as 117 can be the client. The protocol should be internationalized, sup- 118 porting queries and attributes in different languages. 120 oScalable. There can be millions of clients, and thousands of 121 servers for a particular service. 123 oMildly Dynamic. The attributes which characterize the service pro- 124 vided by some server do not change on small timescales. However, 125 they may change on larger timescales, and this should be handled 126 appropriately. 128 This definition elimnates quite a number of problems which might other- 129 wise be deemed wide area service location. For example: 131 oYellow Pages. The yellow pages service allows you to find pizza 132 parlors in San Antonio which deliver, or cleaners in Boise that 133 are open on Saturday. While this resembles the wide area service 134 problem, its focus differs in many respects. The most important 135 distinction is that location (here, geographic) is a key part of 136 the selection process. This allows for the use of a global, dis- 137 tributed database in each geographic locale. YP is therefore 138 focused on locating regional services. Locating wide area 139 services, on the other hand, is based on multiple attributes, and 140 is global in scope. Furthermore, there is no single attribute on 141 which to hierarchically organize the database. 143 oWhite Pages. The white pages service allows you to find some per- 144 son or service with a specific name, associated with some organi- 145 zation. Like the yellow pages service, it is based on strict hier- 146 archies for the names. It lacks the multicriteria selection 147 required of yellow pages, however. Its main difference from wide 148 area service location is the assumption of a hierarchy of names. 149 Service attributes are much flatter, by comparsion, and change 150 more frequently than names in a WP database. 152 oWeb Pages. The web page location problem is to find a web page 153 (which is on some web server, of course) which contains the word 154 foo. A slightly more advanced version of this would be to find the 155 web page that talks about some subject. This location problem is 156 different from the wide area service location problem in that it 157 is looking for a document, not a service. The documents are usu- 158 ally sorted and indexed based on either content or meta- 159 information. The result is that searching is not automated, but 160 progresses based on interactive input and trial from a human user. 161 Furthermore, web indexing is based on pull of information by web- 162 bots. Since webbots have no way of knowing when information on a 163 page has changed, the information returned by a search engine is 164 often stale and out of date. 166 oUser Location. When making an Internet telephone call, it is nec- 167 essary to find the address where the called user may be found. 168 This address may depend on time of day (I'm at home after 9pm), 169 callee preferences (If Bob calls, forward to my cell phone), 170 caller preferences (I only want him if he's at work), and status 171 (I'm currently on the phone - try my voicemail). This location 172 service is different in that the attributes characterizing the 173 service to be located (here, the person to be called) change on 174 rapid timescales. Furthermore, there is usually a tie to adminis- 175 trative location when finding a user. When I want to call John 176 Doe, I usually know that John Doe works for Lucent, and so he may 177 be found on a machine under their administrative control. 179 With so many examples of what is not a wide area service location prob- 180 lem, some example of what does quality are useful: 182 oGateway Location. I want to make a call from a PC to someone on 183 the PSTN in Zimbabwe. I need a telephony gateway that speaks H.323 184 and uses the G.729 speech coder. The gateway should accept credit 185 cards for the call. 187 oMedia Server. I need a media server that speaks RTSP, and has all 188 the latest Warner Brothers films in MPEG2 format. 190 oBank Server. I wish to complete an electronic transaction on the 191 Internet. I need to contact some server which will accept Visa 192 cards, and then transfer some kind of token representing elec- 193 tronic cash to me, which I can then use to purchase an item at a 194 web site. 196 oConference Bridge. I need a conference bridge that can handle at 197 least 20 people, and understands H.261. 199 4 Other Protocols 201 With the abundance of existing protocols for finding things on the 202 Internet, it is valuable to comment on why these are not appropriate 203 for wide area service location, and why something else is needed. 205 4.1 Service Location Protocol 207 SLP [1] defines mechanisms whereby a client can locate a service 208 within an administrative domain. The current architecture is centered 209 around the concept of a directory agent, or DA. This device is a 210 server which collects information about services provided by various 211 service agents (SA's) across the network. The SA's register the ser- 212 vices they provide directly with the DA. Clients (also known as user 213 agents, or UA's) wishing to locate a service send a query to the DA, 214 which then searches its database for matches. The DA then returns the 215 list of servers to the client. Clients and SA's must know the IP 216 address of the DA. This can be learned in one of several ways: 217 through static configuration, through DHCP, through multicast adver- 218 tisements from the DA, or through multicast searches performed by the 219 client or SA. 221 This protocol does not scale beyond a single administrative domain 222 for several reasons: 224 1. Registrations of services from SA's to DA's are asynchronous, 225 and the soft-state refresh interval is fixed (the recommended 226 value is around three hours). This means that if thousands of 227 servers attempt to register, the DA may be swamped with bursts 228 of messages. As the number of servers grows, this problem 229 worsens. 231 2. SA's must know the location of all DA's. In a small adminis- 232 trative domain, this is easy. But in a wide area Internet, 233 this is virtually impossible. Having fixed tables of DA's does 234 not scale well, and is not dynamic enough. Using the multicast 235 searching technique will cause an overload on the network, 236 since the scope of such searches is neccesarily unbounded. 237 Having DA's advertise their presence works better, but still 238 causes traffic. With fixed soft-state refresh intervals, the 239 bandwidth used grows linearly with the number of DA's present 240 in the network. 242 3. As the number of servers and services grow, the disk space 243 required for a DA to store information about all of them is 244 excessive. DA's must somehow be able to provide service loca- 245 tion for only a subset of services. 247 4.2 LDAP 249 The Lightweight Directory Access Protocol [2] was designed as a thin 250 front end for accessing an X.500 database. It's applicability has 251 grown, and it is now a more general mechanism for both client and 252 administrative access to distributed databases, X.500 or otherwise. 254 Its main limitation for wide area service location is its reliance on 255 indexing of the database on a single key, and distribution of compo- 256 nents of the database across the network based on that key. Usually, 257 this key is related to some kind of organizational hierarchy. This 258 makes LDAP databases ideal for things like yellow pages and white 259 pages. However, in wide area service location, there is no single 260 attribute upon which the database can be distributed. 262 Furthermore, LDAP requires a great deal of regularity in syntax and 263 semantics in order to function properly. All cooperating databases 264 and clients must use exactly the same schema. Furthermore, it is not 265 feasible to store or search for entries for which the schema is not 266 known a priori. This is problematic for wide area service location, 267 where many remote services are involved, and where the client may not 268 know about the schema. By its nature, the directory supports lookup 269 of entities well, but wide area searches by 'type' very poorly. Wide 270 area service location must be more flexible, allowing more looser use 271 of schema. Furthermore, the schema for any service must be extensible 272 in a de-centralized manner. 274 While a wide area location system based solely on LDAP requires a 275 more robust solution to the problems of server discovery than those 276 given in [3] [4], LDAP could be used by clients to make requests of a 277 wide area service location system. 279 4.3 DNS 281 DNS, like LDAP databases, are based on a hierarchical organization. 282 For DNS, this hierarchy is arranged based on domain name. Unlike 283 LDAP, the queries for the database are based on a single attribute 284 value (the domain name) to be matched. This makes its applicability 285 to wasrv even less than LDAP. DNS is most useful for white pages type 286 of services, which generally rely on a single attribute to match. 288 However, unlike LDAP, DNS has some legacy use in service discovery 289 where the domain of the service is known a priori. (see [5]). There- 290 fore, for those systems that use DNS for wide area service location, 291 [6] and [7] provide a discussion on how to accomplish this. 293 4.4 URN's 295 Another possibility for a wide area service location is the 296 use/resolution of URNs [8]. URNs can support the multi-criteria, 297 location independence, network level and automation requirements. 298 However, URNs at this time do not provide for auto configuration, 299 instant availability and mildly dynamic requirements needed for a 300 wide area location service. Therefore, while we can consider 301 use/resolution of URNs at the client/server interface, they are not 302 appropriate for the system in its entirety. 304 4.5 Whois++ or CIP 306 Whois++ is another type of distributed database [9]. Unlike LDAP, it 307 does not require the use of a strict hierarchy to organize the data- 308 base. Each database is indexed into a collection of forward informa- 309 tion (called a centroid ), which is to other databases. Whois++ 310 servers use the information in centroids to aid query routing by 311 returning referrals to clients. The client then uses the referral to 312 determine where next to query for desired information. 314 This approach has been expanded upon in the Common Indexing Protocol 315 [10], which applies to any type of database, not just whois++. Note 316 that CIP considers only the server to server "back-end" aggregation 317 and distribution of index objects. Client-server protocol exchanges 318 are not considered under the CIP architecture, but are handled with 319 "native" protocols (Whois++, LDAP, etc.) 321 Since index objects aggregate databases, they may have a place in 322 wide area service discovery. However, scalability issues (such as 323 lengthening referral chains and index object size) make it likely 324 that they would be just one component of an overall architecture. 326 5 Security Considerations 328 Wide area service location must be able to provide functions for 329 determining the authenticity of discovered services and their 330 attributes. It is clear by its nature as a wide area discovery 331 protocol that confidentiality is not a WASRV requirement. 333 The WASRV framework itself should not be easily subvertable. That is, 334 messages sent between WASRV agents should be able to be authenticated 335 so that attackers cannot easily divert or bring down this wide area 336 service. 338 The 'autoconfigurability' requirement means that configuration 339 requirements for security should be kept to a minimum even if they 340 cannot be eliminated entirely. 342 6 Conclusion 344 We have defined the problem of wide area service location, identify- 345 ing its key attributes. Examples of service problems which do and do 346 not fit our characterization are described. We then discussed some 347 existing distributed data retrieval protocols which might be used for 348 wide area service location, and shown how they are not appropriate. 350 7 Full Copyright Statement 352 Copyright (C) The Internet Society (1998). All Rights Reserved. 354 This document and translations of it may be copied and furnished to 355 others, and derivative works that comment on or otherwise explain it 356 or assist in its implmentation may be prepared, copied, published and 357 distributed, in whole or in part, without restriction of any kind, 358 provided that the above copyright notice and this paragraph are 359 included on all such copies and derivative works. 361 However, this document itself may not be modified in any way, such as 362 by removing the copyright notice or references to the Internet Soci- 363 ety or other Internet organizations, except as needed for the purpose 364 of developing Internet standards in which case the procedures for 365 copyrights defined in the Internet Standards process must be fol- 366 lowed, or as required to translate it into languages other than 367 English. 369 The limited permissions granted above are perpetual and will not be 370 revoked by the Internet Society or its successors or assigns. 372 This document and the information contained herein is provided on an 373 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 374 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 375 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 376 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 377 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 379 8 Bibliography 381 [1] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, Service loca- 382 tion protocol, Request for Comments (Proposed Standard) 2165, Inter- 383 net Engineering Task Force, June 1997. 385 [2] T. Howes, S. Kille, and M. Wahl, Lightweight directory access 386 protocol (v3), Request for Comments (Proposed Standard) 2251, Inter- 387 net Engineering Task Force, Dec. 1997. 389 [3] R. Moats, LDAP servers finding other LDAP servers, Internet 390 Draft, Internet Engineering Task Force, Nov. 1997. Work in progress. 392 [4] R. Moats, LDAP clients finding LDAP servers, Internet Draft, 393 Internet Engineering Task Force, Nov. 1997. Work in progress. 395 [5] A. Gulbrandsen and P. Vixie, A DNS RR for specifying the location 396 of services (DNS SRV), Request for Comments (Experimental) 2052, 397 Internet Engineering Task Force, Oct. 1996. 399 [6] M. Hamilton, P. Leach, and R. Moats, Finding stuff (how to dis- 400 cover services), Internet Draft, Internet Engineering Task Force, 401 Oct. 1997. Work in progress. 403 [7] M. Hamilton and R. Moats, Advertising services (providing infor- 404 mation to support service discovery), Internet Draft, Internet Engi- 405 neering Task Force, Oct. 1997. Work in progress. 407 [8] K. Sollins, Architectural principles of uniform resource name 408 resolution, Request for Comments (Informational) 2276, Internet Engi- 409 neering Task Force, Jan. 1998. 411 [9] C. Weider, J. Fullton, and S. Spero, Architecture of the whois++ 412 index service, Request for Comments (Proposed Standard) 1913, Inter- 413 net Engineering Task Force, Feb. 1996. 415 [10] M. Mealling and J. Allen, The architecture of the common index- 416 ing protocol (CIP), Internet Draft, Internet Engineering Task Force, 417 Dec. 1997. Work in progress. 419 9 Authors Addresses 421 Jonathan Rosenberg 422 Lucent Technologies, Bell Laboratories 423 101 Crawfords Corner Rd. 424 Holmdel, NJ 07733 425 Rm. 4C-526 426 email: jdrosen@bell-labs.com 428 Erik Guttman 429 Sun Microsystems 430 Bahnstr. 2 431 74915 Waibstadt 432 Germany 433 email: Erik.Guttman@sun.com 435 Ryan Moats 436 AT&T 437 15621 Drexel Circle 438 Omaha, NE 68135-2358 439 email: jayhawk@att.com 441 Henning Schulzrinne 442 Columbia University 443 M/S 0401 444 1214 Amsterdam Ave. 445 New York, NY 10027-7003 446 email: schulzrinne@cs.columbia.edu