idnits 2.17.1 draft-ietf-iptel-gwloc-framework-03.txt: 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 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 "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 (June 10, 1999) is 9081 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 1010 looks like a reference -- Missing reference section? '2' on line 1015 looks like a reference -- Missing reference section? '3' on line 1019 looks like a reference -- Missing reference section? '4' on line 1023 looks like a reference -- Missing reference section? '5' on line 1027 looks like a reference -- Missing reference section? '6' on line 1031 looks like a reference -- Missing reference section? '7' on line 1035 looks like a reference -- Missing reference section? '8' on line 1039 looks like a reference -- Missing reference section? '9' on line 1043 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 11 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 J.Rosenberg,H.Schulzrinne 3 draft-ietf-iptel-gwloc-framework-03.txt Bell Labs/Columbia U. 4 June 10, 1999 5 Expires: December 1999 7 A Framework for a Gateway Location Protocol 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document serves as a framework for the Gateway Location Protocol 33 (GLP), which supports the discovery and exchange of IP telephony 34 gateway routing tables between providers. The document defines the 35 problem of gateway location, and motivates the need for the protocol. 36 It presents an architectural framework for GLP, defines terminology, 37 specifies the various protocol elements and their functions, 38 overviews the services provided by the protocol, and discusses how it 39 fits into the broader context of Internet telephony. 41 1 Introduction 43 This document serves as a framework for the Gateway Location Protocol 44 (GLP), which supports the discovery and exchange of IP telephony 45 gateway routing tables between providers. The document defines the 46 problem of gateway location, and motivates the need for the protocol. 47 It presents an architectural framework for GLP, defines terminology, 48 specifies the various protocol elements and their functions, 49 overviews the services provided by the protocol, and discusses how it 50 fits into the broader context of Internet telephony. 52 2 Terminology 54 We define the following terms. Note that there are other definitions 55 for these terms, outside of the context of gateway location. Our 56 definitions aren't general, but refer to the specific meaning here: 58 Gateway: A device with some sort of circuit switched network 59 connectivity and IP connectivity, capable of initiating and 60 terminating IP telephony signaling protocols, and capable of 61 initiating and terminating telephone network signaling 62 protocols. 64 End User: The end user is usually (but not necessarily) a human 65 being, and is the party who is the ultimate initiator or 66 recipient of calls. 68 Calling Device: The calling device is a physical entity which has IP 69 connectivity. It is under the direction of an end user who 70 wishes to place a call. The end user may or may not be directly 71 controlling the calling device. If the calling device is a PC, 72 the end user is directly controlling it. If, however, the 73 calling device is a telephony gateway, the end user may be 74 accessing it through a telephone. 76 Gatekeeper: The H.323 gatekeeper element, defined in [1]. 78 SIP Server: The Session Initiation Protocol proxy server, defined in 79 [2]. 81 Call Agent: The MGCP call agent, defined in [3]. 83 GSTN: The Global Switched Telephone Network, which is the worldwide 84 circuit switched network. 86 Signaling Server: A signaling server is an entity which is capable of 87 receiving and sending signaling messages for some IP telephony 88 signaling protocol, such as H.323 or SIP. Generally speaking, a 89 signaling server is a gatekeeper, SIP server, or call agent. 91 Location Server (LS): A logical entity with IP connectivity which has 92 knowledge of gateways that can be used to terminate calls 93 towards the GSTN. The LS is the main entity that participates in 94 the gateway location protocol. The LS is generally a point of 95 contact for end users for completing calls to the telephony 96 network. An LS may also be responsible for propagation of 97 gateway information to other LS's. An LS may be coresident with 98 an H.323 gatekeeper or SIP server, but this is not required. 100 Internet Telephony Administrative Domain (ITAD): The set of resources 101 (gateways and Location Servers) under the control of a single 102 administrative authority. End users are customers of an ITAD. 104 Provider: The administrator of an ITAD. 106 Location Server Policy: The set of rules which dictate how a location 107 server processes information it receives via GLP. This includes 108 rules for aggregating, propagating, generating, and accepting 109 information. 111 End User Policy: Preferences that an end user has about how a call 112 towards the GSTN should be routed. 114 Gateway Information Base (GIB): The database of gateways an LS builds 115 up as a result of participation in GLP. 117 Peers: Two LS's are peers when they have a persistent connection 118 between them over which gateway information is exchanged. 120 Internal peers: Peers that both reside within the same ITAD. 122 External peers: Peers that reside within different ITADs. 124 Originating Location Server: A Location Server which first generates 125 a route to a gateway in its ITAD. 127 3 Motivation and Problem Definition 129 As IP telephony gateways grow in terms of numbers and usage, managing 130 their operation will become increasingly complex. One of the 131 difficult tasks is that of gateway location, also known as gateway 132 selection, path selection, gateway discovery, and gateway routing. 133 The problem occurs when a calling device (such as a telephony gateway 134 or a PC with IP telephony software) on an IP network needs to 135 complete a call to a phone number that represents a terminal on a 136 circuit switched telephone network. Since the intended target of the 137 call resides in a circuit switched network, and the caller is 138 initiating the call from an IP host, a telephony gateway must be 139 used. The gateway functions as a conversion point for media and 140 signaling, converting between the protocols used on the IP network, 141 and those used in the circuit switched network. 143 The gateway is, in essence, a routing point for an application layer 144 signaling protocol. There may be many gateways which could possibly 145 complete the call from the calling device on the IP network to the 146 called party on the circuit switched network. Choosing such a gateway 147 is a non-trivial process. It is complicated because of the following 148 issues: 150 Number of candidate gateways: It is anticipated that as IP telephony 151 becomes widely deployed, the number of telephony gateways 152 connecting the Internet to the GSTN will become large. 153 Attachment to the GSTN means that the gateway will have 154 connectivity to the nearly billion terminals reachable on this 155 network. This means that every gateway could theoretically 156 complete a call to any terminal on the GSTN. As such, the number 157 of candidate gateways for completing a call may be very large. 159 Business Relationships: In reality, the owner of a gateway is 160 unlikely to make the gateway available to any user who wishes to 161 connect to it. The gateway provides a useful service, and incurs 162 cost when completing calls towards the circuit switched network. 163 As a result, providers of gateways will, in many cases, wish to 164 charge for use of these gateways. This may restrict usage of the 165 gateway to those users who have, in some fashion, an established 166 relationship with the gateway provider. 168 Provider Policy: In all likelihood, an end user who wishes to make 169 use of a gateway service will not compensate the gateway 170 provider directly. The end user may have a relationship with an 171 IP telephony service provider which acts as an intermediary to 172 providers of gateways. The IP telephony service provider may 173 have gateways of its own as well. In this case, the IP telephony 174 service provider may have policies regarding the usage of 175 various gateways from other providers by its customers. These 176 policies must figure into the selection process. 178 End User Policy: In some cases, the end user may have specific 179 requirements regarding the gateway selection. The end user may 180 need a specific feature, or have a preference for a certain 181 provider. These need to be taken into account as well. 183 Capacity: All gateways are not created equal. Some are large, capable 184 of supporting hundreds or even thousands of simultaneous calls. 185 Others, such as residential gateways, may only support one or 186 two calls. The process for selecting gateways should allow 187 gateway capacity to play a role. It is particularly desirable to 188 support some form of load balancing across gateways based on 189 their capacities. 191 Protocol and Feature Compatibilities: The calling party may be using 192 a specific signaling or media protocol that is not supported by 193 all gateways. 195 From these issues, it becomes evident that the selection of a gateway 196 is driven in large part by the policies of various parties, and by 197 the relationships established between these parties. As such, there 198 cannot be a global "directory of gateways" in which users look up 199 phone numbers. Rather, information on availability of gateways must 200 be exchanged by providers, and subject to policy, made available 201 locally and then propagated to other providers. This would allow each 202 provider to build up its own local database of available gateways - 203 such a database being very different for each provider depending on 204 policy. 206 From this, we can conclude that a protocol is needed between 207 administrative domains for exchange of gateway routing information. 208 The protocol that provides these functions is the Gateway Location 209 Protocol (GLP). GLP provides a specific set of functions: 211 o Establishment and maintenance of peering relationships between 212 providers 214 o Exchange and synchronization of gateway routing information 215 between providers 217 o Propagation of learned gateway routing information to other 218 providers in a timely and scalable fashion 220 o Definition of the syntax and semantics of the data which 221 describe telephony gateway routes 223 GLP can be generally summarized as an inter-domain IP telephony 224 gateway routing protocol. 226 4 Related Problems 228 At a high level, the problem GLP solves appears to be a mapping 229 problem: given an input telephone number, determine, based on some 230 criteria, the address of a telephony gateway. For this reason, the 231 gateway location problem is often called a "phone number to IP 232 address translation problem". This is an over-simplification, 233 however. There are at least three separate problems, all of which can 234 be classified as a "phone number to IP address translation problem": 236 o Given a phone number that corresponds to a terminal on a 237 circuit switched network, determine the IP address of a 238 gateway capable of completing a call to that phone number. 240 o Given a phone number that corresponds to a specific host on 241 the Internet (this host may have a phone number in order to 242 facilitate calls to it from the circuit switched network), 243 determine the IP address of this host. 245 o Given a phone number that corresponds to a user of a terminal 246 on a circuit switched network, determine the IP address of an 247 IP terminal which is owned by the same user. 249 The last of these three mapping functions is useful for services 250 where the PC serves as an interface for the phone. One such service 251 is the delivery of an instant message to a PC when the user's phone 252 rings. To deliver this service, a switch in the GSTN is routing a 253 call towards a phone number. It wishes to send an Instant Message to 254 the PC for this user. This switch must somehow have access to the IP 255 network, in order to determine the IP address of the PC corresponding 256 to the user with the given phone number. 258 The second of these mappings is needed to facilitate calls from 259 traditional phones to IP terminals. When a user on the GSTN wishes to 260 call a user with a terminal on the IP network, they need to dial a 261 number identifying that terminal. This number could be an IP address. 262 However, IP addresses are often ephemeral, assigned on demand by DHCP 263 [4] or by dialup network access servers using PPP [5]. The number 264 could be a hostname, obtained through some translation of groups of 265 numbers to letters. However, this is cumbersome. It has been proposed 266 instead to assign phone numbers to IP telephony terminals. A caller 267 on the GSTN would then dial this number as they would any other. This 268 number serves as an alternate name for the IP terminal, in much the 269 same way its hostname serves as a name. A switch in the GSTN must 270 then access the IP network, and obtain the mapping from this number 271 to an IP address for the PC. 273 As a result for both of these cases, the mapping function is a name 274 to address translation problem, where the name happens to be 275 represented by a string of digits. Such a translation function is 276 best supported by directory protocols. 278 The first mapping function, however, is fundamentally an address to 279 route translation problem. It is this problem which is considered by 280 GLP. As discussed in Section 3, this mapping depends on local factors 281 such as policies and provider relationships. As a result, the 282 database of available gateways is substantially different for each 283 provider, and needs to be built up through specific inter-provider 284 relationships. It is for this reason that a directory protocol is not 285 appropriate for GLP, whereas it is appropriate for the others. 287 5 Relationship with BGP 288 GLP can be classified as a close cousin of inter-domain IP routing 289 protocols, such as BGP [6]. However, there are important differences 290 between BGP and GLP: 292 o GLP runs at the application layer, not the network layer, 293 where BGP resides. 295 o GLP runs between servers which may be separated by many 296 intermediate networks and IP service providers. BGP runs 297 between routers are usually adjacent. 299 o The information exchanged between GLP peers describes routes 300 to application layer devices, not IP routers, as is done with 301 BGP. 303 o GLP assumes the existence of an underlying IP transport 304 network. This means that servers which exchange GLP routing 305 information need not act as forwarders of signaling messages 306 that are routed based on this information. This is not true in 307 BGP, where the peers must also act as forwarding points (or 308 name an adjacent forwarding hop) for IP packets. 310 o The purpose of GLP is not to establish global connectivity 311 across all ITADs. It is perfectly reasonable for there to be 312 many small islands of GLP connectivity. Each island represents 313 a closed set of administrative relationships. Furthermore, 314 each island can still have complete connectivity to the entire 315 GSTN. This is in sharp contrast to BGP, where the goal is 316 complete connectivity across the Internet. If a set of AS's 317 are isolated from some other set because of a BGP disconnect, 318 no IP network connectivity exists between them. 320 o Gateway routes are far more complex than IP routes (since they 321 reside at the application, not the network layer), with many 322 more parameters which may describe them. 324 o BGP exchanges prefixes which represent a portion of the IP 325 name space. GLP exchanges phone number ranges, representing a 326 portion of the GSTN numbering space. The organization and 327 hierarchies in these two namespaces are different. 329 These differences means that GLP borrows many of the concepts from 330 BGP, but that it is still a different protocol with its own specific 331 functions. 333 6 Example Applications of GLP 335 GLP is a general purpose tool for exchanging of IP telephony routes 336 between providers. GLP does not, in any way, dictate the structure or 337 nature of the relationships between those providers. As a result, GLP 338 has applications for a number of common cases for IP telephony. 340 6.1 Clearinghouses 342 A clearinghouse is a provider that serves as an exchange point 343 between a number of other providers, called the members of the 344 clearinghouse. Each member signs on with the clearinghouse. As part 345 of the agreement, the member makes their gateways available to the 346 other members of the clearinghouse. In exchange, the members have 347 access to the gateways owned by the other members of the 348 clearinghouse. When a gateway belonging to one member makes a call, 349 the clearinghouse plays a key role in determining which member 350 terminates the call. 352 GLP can be applied here as the tool for exchanging routes between the 353 members and the clearinghouse. This is shown in Figure 1. 355 ------ ------ 356 | | | | 357 | M1 | GLP GLP | M2 | 358 | |\ | | /| | 359 ------ \ | | / ------ 360 \ \/ -------------- \/ / 361 ------ \----| |----/ ------ 362 | | | | | | 363 | M3 |--------| Clearinghouse|--------| M4 | 364 | | | | | | 365 ------ /----| |----\ ------ 366 / -------------- \ 367 ------ / \ ------ 368 | |/ \| | 369 | M5 | | M6 | 370 | | | | 371 ------ ------ 373 Figure 1: GLP in the Clearinghouse Application 375 There are 6 member companies, M1 through M6. Each uses GLP to send 376 and receive gateway routes with the clearinghouse provider. 378 6.2 Confederations 380 We refer to a confederation as a group of providers which all agree 381 to share gateways with each other in a full mesh, without using a 382 central clearinghouse. Such a configuration is shown in Figure 2. GLP 383 would run between each pair of providers. 385 ------ ------ 386 | |------| | 387 | M1 | | M2 | 388 | |\ /| | 389 ------ \ / ------ 390 | \/ | 391 | /\ |<-----GLP 392 ------ / \ ------ 393 | |/ \| | 394 | M3 | | M4 | 395 | |------| | 396 ------ ------ 398 Figure 2: GLP for Confederations 400 6.3 Gateway Wholesalers 402 In this application, there are a number of large providers of 403 telephony gateways. Each of these resells its gateway services to 404 medium sized providers. These, in turn, resell to local providers who 405 sell directly to consumers. This is effectively a pyramidal 406 relationship, as shown in Figure 3. 408 Note that in this example, provider M5 resells gateways from both M2 409 and M3. 411 7 Architecture 413 Figure 4 gives the overall architecture of GLP. 415 There are a number of Internet Telephony administrative domains 416 (ITAD's), each of which has at least one Location Server (LS). The 417 LS's, through an out of band means, called the intra-domain protocol, 418 learn about the gateways in their domain. The intra-domain protocol 419 ------ 420 | | 421 | M1 | 422 | | 423 ------ 424 / \ <------- GLP 425 ------ ------ 426 | | | | 427 | M2 | | M3 | 428 | | | | 429 ------ ------ 430 / \ / \ 431 ------ ------ ------ 432 | | | | | | 433 | M4 | | M5 | | M6 | 434 | | | | | | 435 ------ ------ ------ 437 Figure 3: GLP for Wholesalers 439 is represented by the lines between the GW and LS elements in ITAD1 440 in the Figure. The LS's have connections with other LS's, over which 441 they exchange gateway information. These connections are established 442 administratively, and are set up when the IT administrative domains 443 have some kind of agreements in place regarding exchange of gateway 444 information. In the figure, the LS in ITAD1 is connected to the LS in 445 ITAD2, which is in turn connected to the LS in ITAD3. Through the 446 gateway location protocol (GLP), the LS in ITAD2 learns about the two 447 gateways in ITAD1. This information is accessed by end users (EUs) in 448 ITAD2 through the front-end. The front-end is a non-GLP protocol or 449 mechanism by which the LS databases are accessed. In ITAD3, there are 450 both EUs and gateways. The LS in ITAD3 learns about the gateways in 451 ITAD1 through a potentially aggregated advertisement from the LS in 452 ITAD2. 454 8 Elements 456 The architecture in Figure 4 consists of a number of elements. These 457 include the IT administrative domain, end user, gateway, and location 458 server. 460 8.1 IT Administrative Domain 462 An IT administrative domain consists of zero or more gateways, at 463 ITAD1 ITAD2 464 ----------------- ------------------ 465 | | | | 466 | ---- | | ---- | 467 | | GW | | | | EU | | 468 | ---- \ ---- | | ---- / ---- | 469 | | LS | ---------------- | LS | | 470 | ---- ---- | / ---- \ ---- | 471 | | GW | / | /| | EU | | 472 | ---- | / | ---- | 473 | | / | | 474 ------------------ / ------------------ 475 / 476 / 477 --------- /---------- 478 | | | 479 | ---- | 480 | | LS | | 481 | / ---- \ | 482 | ---- || ---- | 483 | | GW | || | EU | | 484 | ---- || ---- | 485 | ---- || ---- | 486 | | GW | / \ | EU | | 487 | ---- ---- | 488 | | 489 --------------------- 490 ITAD3 492 Figure 4: GLP Architecture 494 least one Location Server, and zero or more end users. The gateways 495 and LS's are those which are under the administrative control of a 496 single authority. This means that there is one authority responsible 497 for dictating the policies and configuration of the gateways and 498 LS's. 500 An IT administrative domain need not be the same as an autonomous 501 system. While an AS represents a set of physically connected 502 networks, an IT administrative domain may consist of elements on 503 disparate networks, and even within disparate autonomous systems. 505 The end users within an IT administrative domain are effectively the 506 customers of that IT administrative domain. They are interested in 507 completing calls towards the telephone network, and thus need access 508 to gateways. An end user may be a customer of one IT administrative 509 domain for one call, and then a customer of a different one for the 510 next call. 512 An IT administrative domain need not have any gateways. In this case, 513 its LS learns about gateways in other domains, and makes these 514 available to the end users within its domain. In this case, the IT 515 administrative domain is effectively a virtual IP telephony gateway 516 provider. This is because it provides gateway service, but may not 517 actually own or administer any gateways. 519 An IT administrative domain need not have any end users. In this 520 case, it provides "wholesale" gateway service, making its gateways 521 available to customers in other IT administrative domains. 523 8.2 Gateway 525 A gateway is a logical device which has both IP connectivity and 526 connectivity to some other network, usually a public or private 527 telephone network. The function of the gateway is to translate the 528 media and signaling protocols from one network technology to the 529 other, achieving a transparent connection for the users of the 530 system. 532 A gateway has a number of attributes which characterize the service 533 it provides. Most fundamental among these are the range of phone 534 numbers to which it is willing to provide service. This range may be 535 broken into subranges, and associated with each, some cost metric or 536 cost token. This token indicates some notion of cost or preference 537 for completing calls for this set of the telephone number range. 539 A gateway has attributes which characterize the volume of service 540 which it can provide. These include the number of ports it has (i.e., 541 the number of simultaneous phone calls it can support), and the 542 access link speed. These two together represent some notion of the 543 capacity of the gateway. The metric is useful for allowing Location 544 Servers to decide to route calls to gateways in proportion to the 545 value of the metric, thus achieving a simple form of load balancing. 547 A gateway also has attributes which characterize the type of service 548 it provides. This includes, but is not limited to, signaling 549 protocols supported, telephony features provided, speech codecs 550 understood, and encryption algorithms which are implemented. These 551 attributes may be important in selecting a gateway. In the absence of 552 baseline required features across all gateways (an admirable, but 553 difficult goal), such a set of attributes are required in order to 554 select a gateway with which communications can be established. End 555 users which have specific requirements for the call (such as a user 556 requesting a business class call, in which case certain call features 557 may need to be supported) may wish to make use of such information as 558 well. 560 Some of these attributes are transported in GLP to describe gateways, 561 and others are not. This depends on whether the metric can be 562 reasonably aggregated, and whether it is something which must be 563 conveyed in GLP before the call is set up (as opposed to negotiated 564 or exchanged by the signaling protocols themselves). The philosophy 565 of GLP is to keep it simple, and to favor scalability above abundance 566 of information. 568 8.3 End Users 570 An end user is an entity (usually a human being) which wishes to 571 complete a call through a gateway from an IP network to a terminal on 572 a telephone network. An end user may be a user logged on at a PC with 573 some Internet telephony software. The end user may also be connected 574 to the IP network through an ingress telephone gateway, which the 575 user accessed from telephone handset. This is the case for what is 576 referred to as "phone to phone" service with the IP network used for 577 interexchange transport. 579 End users may, or may not be aware that there is a gateway location 580 service running when they complete a call towards the telephone 581 network. In cases where they are aware, end users may have 582 preferences for how a call is completed. These preferences might 583 include call features which must be supported, quality metrics, owner 584 or administrator, and cost preferences. 586 GLP does not dictate how these preferences are combined with those of 587 the provider to yield the final gateway selection. Nor does GLP 588 support the transport of these preferences to the LS. This transport 589 can be accomplished using the front end, or by some non-protocol 590 means. 592 8.4 Location Server 594 The Location Server (LS) is the main functional entity of the gateway 595 location protocol. It is a logical device which has access to a 596 database of gateways, called the Gateway Information Base (GIB). This 597 database of gateways is constructed by combining the set of locally 598 available gateways and the set of remote gateways (learned through 599 GLP) based on policy. The LS also exports a set of gateways to its 600 peer LS's in other ITAD's. The set of exported gateways is 601 constructed from the set of local gateways and the set of remote 602 gateways (learned through GLP) based on policy. As such, policy plays 603 a central role in the LS operation. This flow of information is shown 604 in Figure 5. 606 | 607 |Intra-domain protocol 608 \/ 609 Local 610 Gateways 612 GLP--> Gateways POLICY Gateways -->GLP 613 IN Out 614 | 615 \/ 616 Gateway 617 Information Base 619 Figure 5: Flow of Information in GLP 621 The GIB built up in the LS allows it to make decisions about IP 622 telephony call routing. When a signaling message arrives at a 623 signaling server, destined for a telephone network address, the LS's 624 database can provide information which is useful for determining a 625 gateway or an additional signaling server to forward the signaling 626 message to. For this reason, an LS may be coresident with a signaling 627 server. When they are not coresident, some means of communication 628 between the LS and the signaling server is needed. This communication 629 is not specifically addressed by GLP, although it is possible that 630 GLP might meet the needs of such a protocol. 632 An ITAD must have at least one LS in order to participate in the 633 gateway location protocol. An ITAD may have more than one LS, for 634 purposes of load balancing, ease of management, or any other reason. 635 In that case, communications between these LS's may need to take 636 place in order to synchronize databases and share information learned 637 from external peers. This is often referred to as the interior 638 component of an inter-domain protocol. GLP includes such a function. 640 Figure 5 shows an LS learning about gateways within the ITAD by means 641 of an intra-domain protocol. There need not be an intra-domain 642 protocol. An LS may operate without knowledge of any locally run 643 gateways. Or, it may know of locally run gateways, but through static 644 configuration. An LS may also be co-resident with a gateway, in which 645 case it would know about the gateway that it is co-resident with. 647 9 Element Interactions 649 9.1 Gateways and Location Servers 651 Gateways must somehow propagate information about their 652 characteristics to an LS within the same ITAD. This LS may, in turn, 653 further propagate this information outside of the ITAD by means of 654 GLP. This LS is called an originating LS for that gateway. When an LS 655 is not coresident with the gateway, the means by which the 656 information gets propagated is not within the scope of the gateway 657 location protocol. The protocol used to accomplish this is generally 658 called an intra-domain protocol. 660 One way in which the information can be propagated is with the 661 Service Location Protocol (SLP) [7]. The gateway can contain a 662 Service Agent (SA), and the LS can act as a Directory Agent (DA). SLP 663 defines procedures by which service information is automatically 664 propagated to DA's from SA's. In this fashion, an LS can learn about 665 gateways in the ITAD. 667 An alternate mechanism for the intra-domain protocol is via the 668 registration procedures of SIP or H.323. The registration procedures 669 provide a means by which users inform a gatekeeper or SIP server 670 about their address. Such a registration procedure could be extended 671 to allow a gateway to effectively register as well. 673 LDAP [8] might also be used for the intra-domain protocol. A gateway 674 can use LDAP to add an entry for itself into the database. If the LS 675 also plays the role of the LDAP server, it will be able to learn 676 about all those gateways in its ITAD. 678 The intra-domain protocol which is used may be different from IT 679 administrative domain to IT administrative domain, and is a matter of 680 local configuration. An LS can also function without an intra-domain 681 protocol. It may learn about gateways through static configuration, 682 or may not know of any local gateways. 684 9.2 Location Server to Location Server 686 The interaction between LS's is what is defined by the gateway 687 location protocol. LS's within the same ITAD use GLP to synchronize 688 information amongst themselves. LS's within different ITADs use GLP 689 to exchange gateway information according to policy. In the former 690 case the LS's are referred to as internal peers, and in the latter 691 case, external peers. 693 LS's communicate with each other through persistent connections. An 694 LS may be connected to one or more other LS's. LS's need not be 695 physically adjacent or part of the same autonomous system. The 696 connection between a pair of LS's is set up administratively. There 697 is no autodiscovery procedure. Two LS's are configured to communicate 698 with each other when their administrators have an agreement in place 699 to exchange gateway information. The syntax and semantics of the 700 messages exchanged over this connection are dictated by the gateway 701 location protocol. The protocol does not dictate the nature of the 702 agreements which must be in place. The GLP merely provides a 703 transport means to exchange whatever gateway routing information is 704 deemed appropriate by the administrators of the system. Details are 705 provided in the GLP protocol specification itself. 707 The rules which govern which gateway information is generated, 708 propagated, and accepted by a gateway is called a location server 709 policy. The gateway location protocol does not dictate or mandate any 710 specific policy. 712 9.2.1 Nature of Exchanged Information 714 The information exchanged by the LS's is a set of routing objects. 715 Each routing object minimally consists of a range of telephone 716 numbers which are reachable, and an IP address which is the next hop 717 towards a gateway which can reach that range. Routing objects are 718 learned from the intra-domain protocol, static configuration, or from 719 LS's in remote ITAD's. An LS may aggregate these routing objects 720 together (merging ranges of telephone numbers, and replacing the IP 721 address with its own IP address, or with the IP address of a 722 signaling server with which the LS is communicating) and then 723 propagate them to another LS. The decision about which objects to 724 aggregate and propagate is known as a route selection operation. How 725 the decision is made is at the discretion of the administrator, and 726 is embodied in the LS policy. The decision can be made based on 727 information learned through the GLP, or through any out of band 728 means. 730 A routing object may have additional information which characterizes 731 the service at the gateway. These attributes include things like 732 protocols, features supported, and capacity. Greater numbers of 733 attributes can provide useful information, however, they come at a 734 cost. Aggregation becomes difficult with more and more information, 735 impacting the scalability of the protocol. 737 Aggregation plays a central role in GLP. In order to facilitate 738 scalability, routing objects can be combined into larger aggregates 739 before being propagated. The mechanisms by which this is done is 740 specified in GLP. Aggregation of application layer routes to gateways 741 is a non-trivial problem. There is a fundamental tradeoff between 742 aggregatability and verbosity. The more information that is present 743 in a GLP routing object, the more difficult it is to aggregate. 745 Consider a simple example of two gateways, A and B, capable of 746 reaching some set of telephone numbers, X and Y, respectively. C is 747 an LS for the ITAD in which A and B are resident. C learns of A and B 748 through some other means. As it turns out, X and Y can be combined 749 into a single address range, Z. C has several options. It can 750 propagate just the advertisement for A, just the advertisement for B, 751 propagate both, or combine them and propagate the aggregate 752 advertisement. In this case C chooses the latter route, and sends a 753 single routing object to one of its peers, D, containing address 754 range Z and its own address, since it is also a signaling server. D 755 is also a signaling server. 757 Some calling device, E, wishes to place a phone call to telephone 758 number T, which happens to be in the address range X. E is configured 759 to use D as its default H.323 gatekeeper. So, E sends a call setup 760 message to D, containing destination address T. D determines that the 761 address T is within the range Z. As D had received a routing object 762 from C containing address range Z, it forwards the call setup message 763 to C. C, in turn, sees that T is within range X, and so it forwards 764 the call setup to A, which terminates the call signaling and 765 initiates a call towards the telephone network. 767 9.2.2 Quality of Service 769 One of the factors which is useful to consider when selecting a 770 gateway is "QoS" - will a call through this gateway suffer 771 sufficiently low loss, delay, and jitter? The quality of a call 772 depends on two components - the QoS on the path between the caller 773 and gateway, and the capacity of the gateway itself (measured in 774 terms of number of circuits available, link capacity, DSP resources, 775 etc.). Determination of the latter requires intricate knowledge of 776 underlying network topologies, and of where the caller is located. 777 This is something handled by QoS routing protocols, and is outside 778 the scope of GLP. 780 However, gateway capacity is not dependent on the caller location or 781 path characteristics. For this reason, a capacity metric of some form 782 is supported by the GLP. This metric represents the static capacity 783 of the gateway, not the dynamic available capacity which varies 784 continuously during the gateways operation. LS's can use this metric 785 as a means of load balancing of calls among gateways. It can also be 786 used as an input to any other policy decision. 788 9.2.3 Cost Information 789 Another useful attribute to propagate is cost metrics. These might 790 represent the amount a particular gateway might charge for a call. 791 Unfortunately, the set of cost structures is potentially unbounded, 792 ranging from the simple (flat rate), to the arbitrarily complex (time 793 and caller dependent, past usage dependent, destination dependent, 794 etc.). For this reason, the GLP does not attempt to define specific 795 cost structures. 797 10 The Front End 799 As a result of the GLP, the LS builds up a database (the GIB) of 800 gateway routes. This information is made available to various 801 entities within the ITAD. The way in which this information is made 802 available is called the front end. It is the visible means by which 803 GLP services are exposed outside of the protocol. 805 10.1 Front End Customers 807 There are several entities which might use the front end to access 808 the GIB. These include, but are not limited to: 810 Signaling Servers: Signaling servers receive signaling messages (such 811 as H.323 or SIP messages) whose purpose is the initiation of IP 812 telephony calls. The destination address of these calls may be a 813 phone number corresponding to a terminal on the GSTN. In order 814 to route these calls to an appropriate gateway, the signaling 815 server will need access to the database built up in the LS. 817 End Users: End users can directly query the LS to get routing 818 information. This allows them to provide detailed information on 819 their requirements. They can then go and contact the next hop 820 signaling server or gateway towards that phone number. 822 Administrators: Administrators may need to access the GIB for 823 maintenance and management functions. 825 When a signaling server contacts the LS to route a phone number, it 826 is usually doing so because a calling device (on behalf of an end 827 user) has attempted to set up a call. As a result, signaling servers 828 effectively act as proxies for end users when accessing the LS 829 database. The communication between the calling devices and their 830 proxies (the signaling servers) is through the signaling protocol. 832 The advantage of this proxy approach is that the actual LS 833 interaction is hidden from the calling device. Therefore, whether the 834 call is to a phone number or IP address is irrelevant. The routing in 835 the case of phone numbers takes place transparently. Proxy mode is 836 also advantageous for thin clients (such as standalone IP telephones) 837 which do not have the interfaces or processing power for a direct 838 query of the LS. 840 The disadvantage of the proxy approach is the same as its advantage - 841 the LS interaction is hidden from the calling device (and thus the 842 end user). In some cases, the end user may have requirements about 843 how they would like the call to be routed. These include preferences 844 about cost, quality, administrator, or call services and protocols. 845 These requirements are called the end user policy. In the proxy 846 approach, the user effectively accesses the service through the 847 signaling protocol. The signaling protocol is not likely to be able 848 to support expression of complex call routing preferences from end 849 users (note however, that SIP does support some forms of caller 850 preferences for call routing [9]). Therefore, direct access from the 851 end user to the LS can provide much richer call routing services. 853 When the end user policy is presented to the LS (either directly or 854 through the signaling protocol), it is at the discretion of the LS 855 how to make use of it. The location server may have its own policies 856 regarding how end user preferences are handled. 858 10.2 Front End Protocols 860 There are numerous protocols that can be used in the front end to 861 access the LS database. GLP does not specify or restrict the 862 possibilities for the front end. It is not clear that it is necessary 863 or even desirable for there to be a single standard for the front 864 end. The various protocols have their strengths and weaknesses. One 865 may be the right solution in some cases, and another in different 866 cases. 868 Some of the possible protocols for the front end are: 870 Service Location Protocol (SLP): SLP has been designed to fit exactly 871 this kind of function. SLP is ideal for locating servers 872 described by a set of attributes. In this case, the server is a 873 gateway (or next hop towards the gateway), and the attributes 874 are the end user policy. The end user is an SLP UA, and the LS 875 is an SLP DA. The Service Query is used to ask for a gateway 876 with a particular set of attributes. 878 Lightweight Directory Access Protocol (LDAP): LDAP is used for 879 accessing distributed databases. Since the LS server contains a 880 database, LDAP could be used to query it. 882 Web Page: The LS could have a web front end. Users could enter 883 queries into a form, and the matching gateways returned in the 884 response. This access mechanism is more appropriate for human 885 access, however. A signaling server would not likely access the 886 front end through a web page. 888 GLP: The protocols discussed above are all of the query-response 889 type. There is no reason why the LS access must be of this form. 890 It is perfectly acceptable for the access to be through complete 891 database synchronization, so that the entity accessing the LS 892 database effectively has a full copy of it. If this approach 893 were desired, GLP itself is an appropriate mechanism. This 894 approach has obvious drawbacks, but nothing precludes it from 895 being done. 897 11 Number Translations 899 The model for GLP is that of many gateways, each of which has some 900 set of phone numbers they are willing to terminate IP calls towards. 901 Often, this set will be based on the set of telephone numbers which 902 are in close geographic proximity to the gateway. For example, a 903 gateway in New York might be willing to terminate calls to the 212 904 and 718 area codes. Of course, it is up to the administrator to 905 decide on what phone numbers the gateway is willing to call. 907 However, certain phone numbers don't represent GSTN terminals at all, 908 but rather they represent services. An example of such numbers are 909 700, 800 and 900 numbers. In the telephone network, these are 910 actually mapped to routable telephone numbers, often based on complex 911 formulae. A classic example is time of day based translation. 913 While nothing prevents a gateway from advertising reachability to 914 these kinds of numbers, this usage is discouraged. Since GLP is a 915 routing protocol, the routes it propagates should be to routable 916 numbers, not to names which are eventually translated to routable 917 numbers. Numerous problems arise when GLP is used to propagate routes 918 to these numbers: 920 o Often, these numbers have only local significance. Calls to an 921 800 number made from New York might terminate in a New York 922 office of a company, while calls made from California will 923 terminate in a California branch. If this 800 number is 924 injected into GLP by a gateway in New York, it could be 925 propagated to other LS's with end users in California. If this 926 route is used, calls may be not be routed as intended. 928 o The call signaling paths might be very suboptimal. Consider a 929 gateway in New York that advertises an 800 number that maps to 930 a phone in California. This number is propagated by GLP, 931 eventually being learned by an LS with end users in 932 California. When one of them dials this number, the call is 933 routed over the IP network towards New York, where it hits the 934 gateway, and then is routed over the GSTN back to California. 935 This is a waste of resources. Had the 800 number been 936 translated before the gateway routing function was invoked, a 937 California gateway could have been accessed directly 939 As a result, it is more efficient to perform translations of these 940 special numbers before the LS routing databases are accessed. How 941 this translation is done is outside the scope of GLP. It can be 942 accomplished by the calling device before making the call, or by a 943 signaling server before it accesses the LS database. 945 12 Security Considerations 947 Security is an important component in GLP. The GLP model assumes a 948 level of trust between peer LS's that exchange information. This 949 information is used to propagate information which determines where 950 calls will be routed. If this information were incorrect, it could 951 cause complete misrouting of calls. This enables a significant denial 952 of service attack. The information might also be propagated to other 953 ITADs, causing the problem to potentially spread. As a result, mutual 954 authentication of peer LS's is critical. Furthermore, message 955 integrity is required. 957 Since the relationships between LS's are based on pre-arranged 958 administrative relationships, shared secrets seem an appropriate 959 mechanism for the authentication and integrity. 961 As routing objects can be passed via one LS to another, there is a 962 need for some sort of end to end authentication as well. However, 963 aggregation will cause the routing objects to be modified, and 964 therefore authentication can only take place from the point of last 965 aggregation to the receiving LS's. 967 GLP messages may contain potentially sensitive information. They 968 represent the routing capabilities of an ITAD. Such information might 969 be used by corporate competitors to determine the network topology 970 and capacity of the ITAD. As a result, encryption of messages is also 971 supported in GLP. 973 13 Acknowledgments 975 The authors would like to thank Matt Squire and Hussein Salama for 976 their detailed comments on this document. 978 14 Changes from -02 980 o Added a problem definition and motivation section 981 o Added a section discussing the relationship with other "phone 982 number to IP address" mapping protocols 984 o Added a section discussing the differences between GLP and BGP 986 o Added a section giving example GLP configurations 988 o Added some additional definitions, including the term Gateway 989 Information Base (GIB) to represent the IP telephony 990 equivalent of the RIB 992 o Clarified that gateway capacity is not a dynamic metric 994 o Added a figure representing the flow of information in an LS 996 o Added acknowledgments section 998 o Added mention of the fact that GLP will include the equivalent 999 of I-BGP 1001 o Made the concept of the front end more explicit, and clarified 1002 that signaling servers can also access the front end 1004 o Added GLP as a corner case front end protocol 1006 o Added discussion of GLP usage with 800 numbers 1008 15 Bibliography 1010 [1] International Telecommunication Union, "Visual telephone systems 1011 and equipment for local area networks which provide a non-guaranteed 1012 quality of service," Recommendation H.323, Telecommunication 1013 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 1015 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1016 session initiation protocol," Request for Comments (Proposed 1017 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 1019 [3] M. Arango, A. Dugan, I. Elliott, C. Huitema, and S. Pickett, 1020 "Media gateway control protocol (MGCP)," Internet Draft, Internet 1021 Engineering Task Force, Feb. 1999. Work in progress. 1023 [4] R. Droms, "Dynamic host configuration protocol," Request for 1024 Comments (Draft Standard) 2131, Internet Engineering Task Force, Mar. 1025 1997. 1027 [5] W. Simpson and Editor, "The point-to-point protocol (PPP)," 1028 Request for Comments (Standard) 1661, Internet Engineering Task 1029 Force, July 1994. 1031 [6] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4)," 1032 Request for Comments (Draft Standard) 1771, Internet Engineering Task 1033 Force, Mar. 1995. 1035 [7] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, "Service 1036 location protocol," Request for Comments (Proposed Standard) 2165, 1037 Internet Engineering Task Force, June 1997. 1039 [8] W. Yeong, T. Howes, and S. Kille, "Lightweight directory access 1040 protocol," Request for Comments (Draft Standard) 1777, Internet 1041 Engineering Task Force, Mar. 1995. 1043 [9] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and 1044 callee capabilities," Internet Draft, Internet Engineering Task 1045 Force, Mar. 1999. Work in progress. 1047 16 Authors Addresses 1049 Jonathan Rosenberg 1050 Lucent Technologies, Bell Laboratories 1051 101 Crawfords Corner Rd. 1052 Holmdel, NJ 07733 1053 Rm. 4C-526 1054 email: jdrosen@bell-labs.com 1056 Henning Schulzrinne 1057 Columbia University 1058 M/S 0401 1059 1214 Amsterdam Ave. 1060 New York, NY 10027-7003 1061 email: schulzrinne@cs.columbia.edu 1063 Table of Contents 1065 1 Introduction ........................................ 1 1066 2 Terminology ......................................... 2 1067 3 Motivation and Problem Definition ................... 3 1068 4 Related Problems .................................... 5 1069 5 Relationship with BGP ............................... 6 1070 6 Example Applications of GLP ......................... 7 1071 6.1 Clearinghouses ...................................... 8 1072 6.2 Confederations ...................................... 9 1073 6.3 Gateway Wholesalers ................................. 9 1074 7 Architecture ........................................ 9 1075 8 Elements ............................................ 10 1076 8.1 IT Administrative Domain ............................ 10 1077 8.2 Gateway ............................................. 12 1078 8.3 End Users ........................................... 13 1079 8.4 Location Server ..................................... 13 1080 9 Element Interactions ................................ 15 1081 9.1 Gateways and Location Servers ....................... 15 1082 9.2 Location Server to Location Server .................. 15 1083 9.2.1 Nature of Exchanged Information ..................... 16 1084 9.2.2 Quality of Service .................................. 17 1085 9.2.3 Cost Information .................................... 17 1086 10 The Front End ....................................... 18 1087 10.1 Front End Customers ................................. 18 1088 10.2 Front End Protocols ................................. 19 1089 11 Number Translations ................................. 20 1090 12 Security Considerations ............................. 21 1091 13 Acknowledgments ..................................... 21 1092 14 Changes from -02 .................................... 21 1093 15 Bibliography ........................................ 22 1094 16 Authors Addresses ................................... 23