idnits 2.17.1 draft-ietf-iptel-gwloc-framework-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 8 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 9 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 (July 7, 1998) is 9418 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 376 looks like a reference -- Missing reference section? '2' on line 381 looks like a reference -- Missing reference section? '3' on line 385 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force IPTEL WG 2 INTERNET-DRAFT Jonathan Rosenberg 3 draft-ietf-iptel-gwloc-framework-00.txt Bell Laboratories 4 Henning Schulzrinne 5 Columbia U. 6 July 7, 1998 7 Expires: January 7, 1999 9 A Framework for a Gateway Location Protocol 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft. Internet-Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute work- 16 ing documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference mate- 21 rial or to cite them other than as ``work in progress''. 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Distribution of this document is unlimited. 31 1 Abstract 33 This document serves as a framework for developing a protocol for IP 34 telephony gateway location. It defines the problem in detail, and 35 overviews features and requirements for a protocol solution. It also 36 defines some baseline terms and presents an architectural view of the 37 problem. 39 2 Introduction 41 While there seems to be agreement that a protocol mechanism is needed 42 to assist in routing IP telephony calls to remote gateways, there is 43 not yet consensus on exactly what this means, or what the require- 44 ments for such a protocol are. This document defines the problem, 45 proposes an architecture for discussion, defines common terms, and 46 presents a set of requirements. 48 3 Problem Definition 50 We can state the problem in its most general terms as follows: 52 There exist some set of IP telephony gateways, each of which are 53 characterized by a set of attributes. An IP host, which we generi- 54 cally call a gateway location client, wishes to complete an IP tele- 55 phony call through one of these gateways. The client has requirements 56 concerning values for some of the attributes. Some protocol mechanism 57 is required to allow the client to determine at least one gateway 58 among the set which meet the criteria. As new gateways become opera- 59 tional, old ones go offline, or attributes of existing gateways 60 change, this information should become available to the client in an 61 automatic way through the protocol. The information is made available 62 by having other hosts, called gateway location servers, propagate 63 information about some subset of the gateways for which each has 64 authority. If this subset is of size 1, the gateway itself may act as 65 a server. Otherwise, some proxy which obtains information about the 66 gateways out of band may act as a server. The protocol must provide 67 for discovery. That is, it should be possible for a new client to 68 join the system, and be able to learn about the gateways advertised 69 by the various servers, without having to establish an explicit con- 70 nection with each server. 72 This general problem can be instantiated in a number of specific 73 instances, as defined below. These instances are not meant to be 74 exhaustive or required. The protocol generically defines operation 75 between gateway location clients and gateway location servers. Its 76 specific usage in any or none of the scenarios below is entirely the 77 choice of the implementor. 79 3.1 H.323 Gatekeeper to Gatekeeper Interzone 81 The gateway location protocol can be used with ITU H.323 [1]. This 82 scenario is depicted in Figure 1. There are a large number of zones, 83 each of which has one or more gatekeepers. Each gatekeeper is respon- 84 sible for some set of the gateways in each zone. Responsibility, 85 here, implies that the gatekeeper know (1) whether the gateway is up 86 or down, and (2) the attributes for each gateway. The means by which 87 this is known may be through RAS, using the gateway location protocol 88 again, on a smaller scale, as described below, or via some other 89 means, such as SNMP. 91 Each gatekeeper acts as both a gateway location client and gateway 92 location server. While acting as server, it distributes information 93 about the gateways its responsible for, via the protocol mechanism. 94 This information is then obtained by the other gatekeepers, acting as 95 gateway location clients. 97 Zone 1 Zone 2 Zone 3 Zone N 98 ---------- ---------- ---------- ---------- 99 | | | | | | | | 100 | GW GW | | GW GW | | GW GW | | GW GW | 101 | | | | | | | | 102 | GW GW | | GW GW | | GW GW | .. | GW GW | 103 | | | | | | | | 104 | GK | | GK | | GK GK | | GK | 105 | /\ | | /\ | |/\ /\ | | /\ | 106 ----||---- -----||---- -||---||-- -----||--- 107 || || || || || 108 -||--------------||---------||---||-------------||-- 109 | \/ \/ \/ \/ \/ | 110 | Protocol Operation | 111 | | 112 ----------------------------------------------------- 114 Figure 1: Interzone Operation 116 As new zones come up, they can join protocol operation and automati- 117 cally learn about gateways in other zones. 119 To make use of the protocol, an H.323 terminal would make a gate- 120 keeper routed call through its local gatekeeper. The alias address 121 listed in the setup message would be a telephone number. The gate- 122 keeper receiving the setup would then make use of the gateway loca- 123 tion protocol, acting as a client, and determine the appropriate 124 gateway for completing the call. The attributes for this gateway 125 might include its gatekeeper. The setup message could then be for- 126 warded to this gatekeeper, which would finally forward the call to 127 the destination gateway. Call setup would then proceed normally for 128 the gatekeeper to gatekeeper routed call. 130 Alternatively, an H.323 terminal might send a RAS LRQ (Location 131 Request) message to its gatekeeper, containing the desired telephone 132 number in the alias address. The gatekeeper could then act as a gate- 133 way location client, and determine the gateway appropriate for reach- 134 ing the given number. The call signaling address of the gateway (or 135 its gatekeeper) can then be returned in the response to the LRQ. 137 Note that the above diagram does not imply that all zones in the 138 Internet are participating in the protocol operation. It should be 139 possible to support many instances of the protocol, with some (possi- 140 bly overlapping) subset of zones participating in each instance. 141 Zones would only participate in an instance of the protocol if they 142 are interested in sharing gateway information with other zones par- 143 ticipating in that instance. For example, a set of service providers 144 may get together to form a confederation, sharing gateways and using 145 some coordinated billing agreements. There are many examples of such 146 confederations in existence today. The confederation may run a single 147 instance of the protocol. Each participating ISP would have its own 148 gatekeepers act as both gateway location clients and gateway location 149 servers in that instance. An ISP who is a member of multiple confed- 150 erations might participate in two instances of the protocol, one for 151 each confederation of which it is a member. 153 3.2 H.323 Intra Zone Discovery 155 The protocol can also be used to allow a gatekeeper to discover the 156 gateways inside of its own zone. This scenario is depicted in Figure 157 2 159 ---- ---- ---- ---- 160 | GW | | GW | | GW | | GW | 161 -|-- -|-- -|-- -|-- 162 | | | | 163 \/ \/ \/ \/ 164 ------------------------------------------ 165 | Protocol Operation | 166 ------------------------------------------ 167 | | 168 | | 169 \/ \/ 170 ---- ---- 171 | GK | | GK | 172 ---- ---- 174 Figure 2: Intra Zone Discovery 176 Here, the gateways inside of the zone act as gateway location 177 clients, and the gatekeepers act as gateway location servers. As the 178 protocol is really engineered for wide area operation, its usage in 179 this scenario is more useful when a zone is extremely large, 180 containing many gateways and gatekeepers. It is also most useful when 181 it is desired for each gatekeeper to learn about each gateway. 183 3.3 Wide Area SIP Operation 185 As it is desirable to make the gateway location protocol independent 186 of the underlying IP telephony signaling protocol, it can be used 187 with SIP [2] (or any of the many proprietary mechanisms still in 188 use). Its usage with SIP is depicted in Figure 3. 190 Domain a.com Domain b.com 191 - - - - - - - - - - - - - - - - - - - - - 192 | ---- ---- | | ---- ---- | 193 | GW | | GW | | GW | | GW | 194 | -|-- -|-- | | -|-- -|-- | 195 | | | | 196 | | ---- | | | | ---- | | 197 | | SV | | | | SV | | 198 | | ---- | | | | ---- | | 199 | /\ | | /\ | 200 | | | | | | | | | | 201 - - - - - - - - - - - - - - - - - - - - - 202 | | | | | | 203 \/ | \/ \/ | \/ 204 ------------------------------------------ 205 | Protocol Operation | 206 ------------------------------------------ 208 Figure 3: SIP Operation 210 Here, gateways in each domain act as gateway location servers. They 211 each propagate information about their own attributes, via the proto- 212 col, over the wide area network. SIP Servers (SV in the diagram) 213 obtain these attributes. When a client (not shown) makes a call to 214 the PSTN, it forwards the SIP INVITE to its local proxy server, with 215 the Request URI and To field containing a telephone URL. This proxy 216 server can then use the protocol to determine the appropriate gate- 217 way. The gateway can then be returned to the client using a SIP redi- 218 rect response, or the server can forward the call to the gateway 219 directly, acting as a proxy. 221 4 Requirements 222 Here, we discuss the requirements of the protocol to solve the 223 defined problem. Note that many of these are similar to the require- 224 ments for discovering wide area services in general [3]: 226 oMulti-criteria. The client desires a gateway which can be charac- 227 terized by a number of attributes. The client should be able to 228 express the desired attributes of the gateway, and get back a 229 gateway whose service meets the criteria. There should be no arbi- 230 trary restriction on the type, values, or number of attributes 231 which can potentially characterize a gateway. Obviously, some kind 232 of standardization of baseline attributes, and their syntax and 233 semantics, will be required for interoperability. However, it must 234 be possible for implementors to define and register their own 235 attributes. The protocol must provide a way to maintain minimum 236 interoperability when a gateway location client does not under- 237 stand some of the attributes sent by the server. 239 oLocation Independent. It should not be necessary for the gateway 240 location client to know the domain, zone, IP address, administra- 241 tor, or any other type of name of a gateway in order to locate and 242 use it. 244 oAuto Configured. It should be straightfoward to configure new 245 clients and servers to use the protocol. A new gateway should 246 automatically be discoverable, requiring no new configuration on 247 the part of existing clients, and little or no setting of 248 addresses or other parameters in the new gateway (or the server 249 representing it). 251 oRapid Availability. When a gateway is first brought on line, it 252 should become visible and accessible to clients rapidly. 254 oAutomated. The location process should be automated, and not rely 255 on interactive input from a user to satisfy a reasonable query. 256 However, the protocol should not prevent interactive sessions. 258 oRapid. The gateway location process should occur as rapidly as 259 possible. It is one component of many in the post-dial delay. It 260 is therefore desirable to avoid wide area, distributed database 261 searches in order to determine a suitable gateway. 263 oPolicy Support. The protocol must support policy. This means that 264 it must be possible for a client to eliminate certain gateways 265 from the selection process based on any desired combination of 266 attributes. It must also be possible for a server to specify pol- 267 icy, so that it can restrict the set of clients which can access 268 it. 270 oWorldwide. The location of a desired gateway can be anywhere, as 271 can be the client. The protocol should be internationalized, sup- 272 porting queries and attributes in different languages. 274 oScalable. There can be millions of clients, servers, and gateways, 275 and the protocol will still operate correctly. 277 oMildly Dynamic. The attributes which characterize the service pro- 278 vided by the gateway do not change on small timescales. However, 279 they may change on larger timescales, and this should be handled 280 appropriately. 282 oSecurity. Encryption of messages must be supported. Authentication 283 and non-repudiation of attributes for gateways must be supported. 285 oMultiple Instances. It should be possible to run multiple 286 instances of the protocol, so that gateway location servers in an 287 instance make their gateways available only to those gateway loca- 288 tion clients running in the instance. 290 oSignaling Protocol Independent. The protocol should be independent 291 of the underlying IP telephony signaling protocol, be it H.323, 292 SIP, or some other proprietary protocol. 294 4.1 Possible Attributes 296 As the protocol involves selection of gateways based on attributes, 297 it is necessary to define a base set of attributes. Below are a par- 298 tial list of potential attributes: 300 oPhone Prefixes Allowed: The set of phone number prefixes which 301 this gateway is permitted to call. 303 oGateway Address: The IP address of the gateway. 305 oCodecs Supported: List of codecs supported by the gateway. 307 oSignaling Protocols Supported: List of signaling protocols and 308 versions supported. 310 oCost Plan: Some kind of cost structure describing how much the 311 gateway will bill for calls based on time of day, destination, 312 etc. 314 oBilling Methods: Tokens which describe the ways in which calls 315 through the gateway can be billed. Examples include credit and 316 debit cards, clearinghouse, e-cash, etc. 318 oConfederation or ClearingHouse Memberships: Membership in various 319 confederations. 321 oAdministrator: Name of the corporation that administers the gate- 322 way. 324 oTotal Capacity: Number of lines supported by the gateway. 326 oAvailable Capacity: Estimate of the number of lines still avail- 327 able through the gateway. 329 oFeatures Supported: Supplementary telephony services supported by 330 the gateway, such as multiparty calling, transfer, and forward. 332 oGatekeeper: The gatekeeper for the gateway. 334 5 Security Considerations 336 Security is a critical requirement for a protocol solution. Encryp- 337 tion, authentication, and non-repudiation are minimal requirements. 339 6 Conclusion 341 We have defined the problem of gateway location, proposed a framework 342 for discussing solutions, and defined a set of key requirements for a 343 solution. 345 7 Full Copyright Statement 347 Copyright (C) The Internet Society (1998). All Rights Reserved. 349 This document and translations of it may be copied and furnished to 350 others, and derivative works that comment on or otherwise explain it 351 or assist in its implmentation may be prepared, copied, published and 352 distributed, in whole or in part, without restriction of any kind, 353 provided that the above copyright notice and this paragraph are 354 included on all such copies and derivative works. 356 However, this document itself may not be modified in any way, such as 357 by removing the copyright notice or references to the Internet Soci- 358 ety or other Internet organizations, except as needed for the purpose 359 of developing Internet standards in which case the procedures for 360 copyrights defined in the Internet Standards process must be fol- 361 lowed, or as required to translate it into languages other than 362 English. 364 The limited permissions granted above are perpetual and will not be 365 revoked by the Internet Society or its successors or assigns. 367 This document and the information contained herein is provided on an 368 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 369 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 370 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 371 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 372 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 374 8 Bibliography 376 [1] International Telecommunication Union, Visual telephone systems 377 and equipment for local area networks which provide a non-guaranteed 378 quality of service, Recommendation H.323, Telecommunication Standard- 379 ization Sector of ITU, Geneva, Switzerland, May 1996. 381 [2] M. Handley, H. Schulzrinne, and E. Schooler, SIP: Session initia- 382 tion protocol, Internet Draft, Internet Engineering Task Force, Mar. 383 1998. Work in progress. 385 [3] J. Rosenberg, H. Schulzrinne, E. Guttman, and R. Moats, WASRV 386 architectural principles, Internet Draft, Internet Engineering Task 387 Force, Feb. 1998. Work in progress. 389 9 Authors Addresses 391 Jonathan Rosenberg 392 Lucent Technologies, Bell Laboratories 393 101 Crawfords Corner Rd. 394 Holmdel, NJ 07733 395 Rm. 4C-526 396 email: jdrosen@bell-labs.com 398 Henning Schulzrinne 399 Columbia University 400 M/S 0401 401 1214 Amsterdam Ave. 402 New York, NY 10027-7003 403 email: schulzrinne@cs.columbia.edu