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