idnits 2.17.1 draft-ietf-iptel-gwloc-framework-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (February 11, 1999) is 9205 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 581 looks like a reference -- Missing reference section? '2' on line 586 looks like a reference -- Missing reference section? '3' on line 590 looks like a reference -- Missing reference section? '4' on line 594 looks like a reference -- Missing reference section? '5' on line 598 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force iptel wg 3 Internet Draft J.Rosenberg,H.Schulzrinne 4 draft-ietf-iptel-gwloc-framework-02.txt Bell Labs/Columbia U. 5 February 11, 1999 6 Expires: August 1999 8 A Framework for a Gateway Location Protocol 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1 Abstract 33 This document serves as a framework for a protocol for locating an IP 34 telephony gateway. It defines terminology, specifies the various 35 architectural elements and their functions, overviews the services 36 provided by the protocol, and discusses how it fits into the broader 37 context of Internet telephony. 39 2 Introduction 41 As IP telephony gateways grow in terms of numbers and usage, managing 42 their operation will become increasingly complex. One of the diffi- 43 cult tasks is that of gateway location, also known as gateway selec- 44 tion, path selection, gateway discovery, and gateway routing. The 45 essence of the problem is that an ingress gateway or end user must 46 select a server to which it should forward signaling messages des- 47 tined for a particular PSTN destination. This server may actually be 48 the gateway, or it may be a gatekeeper or SIP server with additional 49 call routing information. This server or gateway may lie in a remote 50 administrative domain, and the selection of the gateway may be based 51 on a number of criteria. 53 To support discovery and location of gateways in remote administra- 54 tive domains, a protocol is being developed, call the Gateway Loca- 55 tion Protocol (GLP). This document serves as a framework for GLP. It 56 defines terminology used in the specification, specifies the various 57 architectural elements and their functions, overviews the services 58 provided by the protocol, and discusses how it fits into the broader 59 context of Internet telephony. 61 3 Terminology 63 We define the following terms. Note that there are other definitions 64 for these terms, outside of the context of gateway location. Our 65 definitions aren't general, but refer to the specific meaning here: 67 o Gateway: A device with some sort of PSTN connectivity and IP 68 connectivity, capable of initiating and terminating IP 69 telephony signaling protocols, and capable of initiating and 70 terminating telephone network signaling protocols. 72 o End User (EU): An entity with IP connectivity which wishes to 73 place a call from an IP network to a user connected only via a 74 telephone network. The end user can be an individual at a PC, 75 an intelligent IP peripheral, or a local gateway for a phone 76 to phone IP telephony call. 78 o Gatekeeper: The H.323 gatekeeper element, defined in [1] 80 o SIP Server: The Session Initiation Protocol proxy server, 81 defined in [2]. 83 o Signaling Server: A signaling server is an entity which is 84 capable of receiving signaling messages for some IP telephony 85 signaling protocol, such as H.323 or SIP, and forwarding the 86 signaling messages to another signaling server or gateway. 87 Generally speaking, a gatekeeper or SIP server. 89 o Location Server (LS): A logical entity with IP connectivity 90 which has knowledge of gateways that can be used to terminate 91 calls towards the PSTN. The LS is the main entity that parti- 92 cipates in the gateway location protocol. The LS is generally 93 a point of contact for end users for completing calls to the 94 telephony network. An LS may also be responsible for propaga- 95 tion of gateway information to other LS's. An LS may be 96 coresident with an H.323 gatekeeper or SIP server, but this is 97 not required. 99 o Administrative Domain: The set of gateways and Location 100 Servers under the control of a single administrative author- 101 ity. End users are customers of an administrative domain. 103 o Location Server Policy: The set of rules which dictate how a 104 location server processes information it receives via GLP. 105 This includes rules for aggregating, propagating, generating, 106 and accepting information. 108 o End User Policy: Preferences that an end user has about how a 109 call towards the PSTN should be routed. 111 4 Architecture 113 Figure 1 gives the overall architectural perspective of the gateway 114 location protocol. 116 AD1 AD2 117 ----------------- ------------------ 118 | | | | 119 | ---- | | ---- | 120 | | GW | | | | EU | | 121 | ---- ---- | | ---- / ---- | 122 | | LS | ---------------- | LS | | 123 | ---- ---- | / ---- ---- | 124 | | GW | / | /| | EU | | 125 | ---- | / | ---- | 126 | | / | | 127 ------------------ / ------------------ 128 / 129 / 130 --------- /---------- 131 | | | 132 | ---- | 133 | | LS | | 134 | / ---- | 135 | ---- || ---- | 136 | | GW | || | EU | | 137 | ---- || ---- | 138 | ---- || ---- | 139 | | GW | / | EU | | 140 | ---- ---- | 141 | | 142 --------------------- 143 AD3 145 Figure 1: GLP Architecture 147 There are a number of administrative domains (AD's), each of which 148 has at least one Location Server (LS). The LS's, through an out of 149 band means, called the intra-domain protocol, learn about the gate- 150 ways in their domain. The intra-domain protocol is represented by the 151 lines between the GW and LS elements in AD1 in the Figure. The LS's 152 have connections with other LS's, over which they exchange gateway 153 information. These connections are established administratively, and 154 are set up when the administrative domains have some kind of agree- 155 ments in place regarding exchange of gateway information. In the fig- 156 ure, the LS in AD1 is connected to the LS in AD2, which is in turn 157 connected to the LS in AD3. Through the gateway location protocol 158 (GLP), the LS in AD2 learns about the two gateways in AD1. This 159 information is accessed by end users (EUs) in AD2 through the front- 160 end. The front-end is a non-GLP protocol or mechanism by which EUs 161 access the information. In AD3, there are both EUs and gateways. The 162 LS in AD3 learns about the gateways in AD1 through a potentially 163 aggregated advertisement from the LS in AD2. 165 The GLP is similar in flavor to inter-domain routing protocols, such 166 as BGP [3]. However, it differs in that the connectivity being 167 expressed is not network level, but represents application level 168 relationships. Furthermore, attributes play a more important role 169 here than in BGP because the protocol is an application, not network, 170 layer protocol. 172 5 Elements 174 The system for gateway location consists of a number of elements. 175 These include the administrative domain, end user, gateway, and loca- 176 tion server. 178 5.1 Administrative Domain 180 An administrative domain consists of zero or more gateways, at least 181 one Location Server, and zero or more end users. The gateways and 182 LS's are those which are under the administrative control of a single 183 authority. This means that there is one authority responsible for 184 dictating the policies and configuration of the gateways and LS's. 186 An administrative domain may not be the same as an autonomous system. 187 While an AS represents a set of physically connected networks, an 188 administrative domain may consist of elements on disparate networks, 189 and even within disparate autonomous systems. 191 The end users within an administrative domain are effectively the 192 customers of that administrative domain. They are interested in com- 193 pleting calls towards the telephone network, and thus need access to 194 gateways. An end user may be a customer of one administrative domain 195 for one call, and then a customer of a different one for the next 196 call. 198 An administrative domain may not have any gateways. In this case, its 199 LS learns about gateways in other domains, and makes these available 200 to the end users within its domain. In this case, the administrative 201 domain is effectively a virtual IP telephony gateway provider. This 202 is because it provides gateway service, but may not actually own or 203 administer any gateways. 205 An administrative domain may not have any end users. In this case, it 206 provides "wholesale" gateway service, making its gateways available 207 to customers in other administrative domains. 209 5.2 Gateway 211 A gateway is a logical device which has both IP connectivity and con- 212 nectivity to some other network, usually a public or private tele- 213 phone network. The function of the gateway is to translate the media 214 and signaling protocols from one network technology to the other, 215 achieving a transparent connection for the users of the system. 217 A gateway has a number of attributes which characterize the service 218 it provides. Most fundamental among these are the range of phone 219 numbers to which it is willing to provide service. This range may be 220 broken into subranges, and associated with each, some cost metric or 221 cost token. This token indicates some notion of cost or preference 222 for completing calls for this set of the telephone number range. 224 Question - can this actually be a "dollar" cost value? There are 225 serious issues with trying to do this. Cost plans can be arbitrarily 226 complex, and be based on many different currencies. Should we provide 227 some simple cost structures (unit of currency per unit time and flat 228 rate), or just use a preference, much like a weight metric associated 229 with a route. 231 A gateway has attributes which characterize the volume of service 232 which it can provide. These include the number of ports it has (i.e., 233 the number of simultaneous phone calls it can support), and the 234 access link speed. These two together represent some notion of the 235 capacity of the gateway. The metric is useful for allowing Location 236 Servers to decide to route calls to gateways in proportion to the 237 value of the metric, thus achieving a simple form of load balancing. 239 A gateway also has attributes which characterize the type of service 240 it provides. This includes, but is not limited to, signaling proto- 241 cols supported, telephony features provided, speech codecs under- 242 stood, and encryption algorithms which are implemented. These attri- 243 butes may be important in selecting a gateway. In the absence of 244 baseline required features across all gateways (an admirable, but 245 difficult goal), such a set of attributes are required in order to 246 select a gateway with which communications can be established. End 247 users which have specific requirements for the call (such as a user 248 requesting a business class call, in which case certain call features 249 may need to be supported) may wish to make use of such information as 250 well. 252 5.3 End Users 254 An end user is an entity which wishes to complete a call through a 255 gateway from an IP network to a terminal on a telephone network. An 256 end user may be a user logged on at a PC with some Internet telephony 257 software. The end user may also be a telephone gateway, dialed by a 258 user from telephone handset. This is the case for the phone to phone 259 service using the IP network for long distance transport. 261 End users may, or may not be aware that there is a gateway location 262 service running when they complete a call towards the telephone net- 263 work. In cases where they are aware, end users may have preferences 264 for how a call is completed. These preferences might include call 265 features which must be supported, quality metrics, owner or adminis- 266 trator, and cost preferences. 268 5.4 Location Server 270 The Location Server (LS) is the main functional entity of the gateway 271 location protocol. It is a logical device which has access to a data- 272 base of gateways, and participates in the gateway location protocol. 273 As a participant, its job is to receive information about gateways 274 from other Location Servers, send information to other Location 275 Servers about gateways it knows about, and to aggregate and forward 276 information about gateways to other LS's. 278 The database built up in the LS allows it to make decisions about IP 279 telephony call routing. When a signaling message arrives at a signal- 280 ing server, destined for a telephone network address, the LS's data- 281 base can provide information which is useful for determining a gate- 282 way or an additional signaling server to forward the signaling mes- 283 sage to. For this reason, an LS may be coresident with a signaling 284 server. 286 An LS is a representative for an administrative domain. An 287 administrative domain must have at least one LS in order to partici- 288 pate in the gateway location protocol. An administrative domain may 289 have more than one LS, for purposes of load balancing, ease of 290 management, or any other reason. 292 One or more of the LS's in an administrative domain may have 293 knowledge of the gateways run by the administrative domain. This 294 knowledge may be configured statically, learned through other proto- 295 cols, or acquired through GLP by placing an LS coresident with the 296 gateway, allowing the gateway to participate in GLP. 298 The information learned from other LS's may be used by an LS to aid 299 in routing calls which originate or transit through the administra- 300 tive domain. 302 A LS may be coresident with an H.323 gatekeeper, SIP server, or MGCP 303 call agent, but this need not be the case. When they are not 304 coresident, some means of communication between the LS and the 305 server, gatekeeper, or call agent is needed. This communication is 306 not addressed by the GLP. 308 6 Element Interactions 310 6.1 Gateways and Location Servers 312 Gateways must somehow propagate information about their characteris- 313 tics to an LS within the same AD which will further propagate this 314 information outside of the AD. That LS is called an originating LS 315 for that gateway. When an LS is not coresident with the gateway, the 316 means by which the information gets propagated is not within the 317 scope of the gateway location protocol. The protocol used to accom- 318 plish this is generally called an intra-domain protocol. 320 One way in which the information can be propagated is with the Ser- 321 vice Location Protocol (SLP) [4]. The gateway can contain a Service 322 Agent (SA), and the LS can act as a Directory Agent (DA). SLP defines 323 procedures by which service information is automatically propagated 324 to DA's from SA's. In this fashion, an LS can learn about gateways in 325 the administrative domain. 327 An alternate mechanism for the intra-domain protocol is via the 328 registration procedures of SIP or H.323. The registration procedures 329 provide a means by which users inform a gatekeeper or SIP server 330 about their address. Such a registration procedure could be extended 331 to allow a gateway to effectively register as well. 333 Other means exist as well. These might include LDAP [5], email, web 334 page, or human based means, such as a phone call or letter. The 335 mechanism which is used may be different from administrative domain 336 to administrative domain, and is a matter of local configuration. The 337 only requirement for the gateway location protocol to operate effec- 338 tively is that this mechanism exist in some form. 340 6.2 Location Server to Location Server 342 The interaction between LS's in adjacent AD's is what is defined by 343 the gateway location protocol. LS's within the same administrative 344 domain may use the protocol as well, but its focus is on inter-domain 345 LS communications. 347 LS's communicate with each other through TCP connections. An LS may 348 be connected to one or more other LS's. LS's need not be physically 349 adjacent or part of the same autonomous system. The TCP connection 350 between a pair of LS's is set up administratively. There is no auto- 351 discovery procedure. Two LS's are configured to communicate with each 352 other when their administrators have an agreement in place to 353 exchange gateway information. The syntax and semantics of the mes- 354 sages exchanged over this connection are dictated by the gateway 355 location protocol. The protocol does not dictate the nature of the 356 agreements which must be in place, nor does it dictate what informa- 357 tion is actually exchanged. The GLP merely provides a transport means 358 to exchange whatever information is deemed appropriate by the 359 administrators of the system. 361 The rules which govern which gateway information is generated, pro- 362 pagated, and accepted by a gateway is called a location server pol- 363 icy. The gateway location protocol does not dictate or mandate any 364 specific policy. 366 When an LS learns about a gateway within its AD through some means 367 outside of the gateway location protocol, and then propagates this 368 information to other LS's through the gateway location protocol, that 369 LS is said to be an originating LS for that gateway. This means that 370 the LS is responsible for determining when an update about the gate- 371 way should be sent. 373 Although GLP is an inter-domain protocol, it may be used between LS's 374 within the same administrative domain. 376 6.2.1 Nature of Exchanged Information 378 The information exchanged by the LS's is a set of routing objects. 379 Each routing object minimally consists of a range of telephone 380 numbers which are reachable, and an IP address which is the next hop 381 towards a gateway which can reach that range. Routing objects are 382 learned from the intra-domain protocol, or from LS's in remote AD's. 384 An LS may aggregate these routing objects together, merging ranges of 385 telephone numbers, and replacing the IP address with its own IP 386 address, or with the IP address of a signaling server with which the 387 LS is communicating, and then propagate them to another LS. The deci- 388 sion about which objects to propagate is known as a route selection 389 operation. How the decision is made is at the discretion of the 390 administrator, and is embodied in the LS policy. The decision can be 391 made based on information learned through the GLP, or through any out 392 of band means. 394 Consider a simple example of two gateways, A and B, capable of reach- 395 ing some set of telephone numbers, X and Y, respectively. C is an LS 396 for the administrative domain in which A and B are resident. C learns 397 of A and B through some other means. As it turns out, X and Y can be 398 combined into a single address range, Z. C has several options. It 399 can propagate just the advertisement for A, just the advertisement 400 for B, propagate both, or combine them and propagate the aggregate 401 advertisement. In this case C chooses the latter route, and sends a 402 single routing object to one of its peers, D, containing address 403 range Z and its own address, since it is also a signaling server. D 404 is also a signaling server. 406 Some client, E, wishes to place a phone call to telephone number T, 407 which happens to be in the address range X. E is configured to use D 408 as its default H.323 gatekeeper. So, E sends a call setup message to 409 D, containing destination address T. D determines that the address T 410 is within the range Z. As D had received a routing object from C con- 411 taining address range Z, it forwards the call setup message to C. C, 412 in turn, sees that T is within range X, and so it forwards the call 413 setup to A, which terminates the call signaling and initiates a call 414 towards the telephone network. 416 A routing object may have additional information which characterizes 417 the service at the gateway. These attributes include things like pro- 418 tocols, features supported, capacity, and cost metrics. Greater 419 numbers of attributes can provide useful information, however, they 420 come at a cost. Aggregation becomes difficult with more and more 421 information, impacting the scalability of the protocol. The GLP will 422 need to strike a reasonable balance between utility of information 423 and scalability. 425 6.2.2 Quality of Service 427 One of the factors which is useful to consider when selecting a gate- 428 way is "QoS" - will a call through this gateway suffer sufficiently 429 low loss, delay, and jitter? The quality of a call depends on two 430 components - the QoS on the path between the caller and gateway, and 431 the capacity of the gateway itself (measured in terms of number of 432 circuits available, link capacity, DSP resources, etc.). Determina- 433 tion of the latter requires intricate knowledge of underlying network 434 topologies, and of where the caller is located. This is something 435 handled by QoS routing protocols, and is outside the scope of GLP. 437 However, gateway capacity is not dependent on the caller location or 438 path characteristics. For this reason, a capacity metric of some form 439 is supported by the GLP. LS's can use it as a means of load balancing 440 of calls among gateways. However, the capacity metric can only be 441 used for purposes of comparing the relative capacities of two gate- 442 ways, and not for learning the absolute number of calls which may be 443 routed to a gateway from the LS. This is because multiple LS's may 444 receive this metric. 446 6.2.3 Cost Information 448 Another useful attribute to propagate is cost metrics. These might 449 represent the amount a particular gateway might charge for a call. 450 Unfortunately, the set of cost structures is potentially unbounded, 451 ranging from the simple (flat rate), to the arbitarily complex (time 452 and caller dependent, past usage dependent, destination dependent, 453 etc.). For this reason, the GLP does not attempt to define specific 454 cost structures. Rather, it provides hooks that allow service provid- 455 ers to use any cost structure they like. 457 6.2.4 Determining when to send an object 459 An LS is free to send an updated routing object at its discretion. 460 Normally, an update is sent if (1) the LS is an originating LS, and 461 the attributes or state of the gateway has changed, (2) the LS has 462 received an updated object, and wishes to propagate it or change 463 other objects which it created as a result of aggregation, (3) the 464 policy of the LS has changed. 466 6.3 End Users and Location Servers 468 The interaction between the end users and location servers is also 469 outside the scope of the gateway location protocol. This interaction 470 is referred to as the front-end, as it provides the visible means by 471 which the gateway location protocol services are exposed. 473 A front end is required when an administrative domain has end users, 474 and these end users wish to complete calls to a telephone network 475 address. This can happen when a user sitting at a PC types a tele- 476 phone number into their IP telephony software, or when an ingress 477 gateway receives a call from a telephone wishing to complete a call 478 to another telephone. In both cases, the end user must determine 479 where to send its signaling messages in order to complete the call. 481 In some cases, the end user may have requirements about how they 482 would like the call to be routed. These include preferences about 483 cost, quality, administrator, or call services and protocols. These 484 requirements are called the end user policy. This policy is distinct 485 from the location server policy. The location server policy includes 486 the providers preferences about which gateways to accept and make 487 available to its customers: the end users in its administrative 488 domain. The location server policy effectively takes the set of all 489 available gateways, and distills them into a list which is acceptable 490 to the provider. The end user policy may then be used to select among 491 those gateways. When an end user policy is expressed, it is the dis- 492 cretion of the administrator whether to use or modify this policy 493 when selecting a gateway. 495 There are two models for the front end. These are called direct and 496 proxy modes. 498 6.3.1 Direct Mode 500 In direct mode, the end user is aware that the call needs to ter- 501 minate on the telephone network, and it directly queries one of the 502 LS's within the administrative domain for the address of a gateway or 503 signaling server which can route the call. This query can contain 504 policy from the end user, or can just contain the telephone number 505 which is desired. The LS receives the query, and after consulting its 506 database, and any existing policy, returns zero or more addresses to 507 the end user. The response to the end user may also contain parame- 508 ters or attributes of the gateway if they are known. 510 Many protocols may be used for direct mode access. The Service Loca- 511 tion Protocol (SLP) is one example; its been designed to fit exactly 512 this kind of need. The end user is an SLP UA, and the LS is an SLP 513 DA. The Service Query is used to ask for a gateway with a particular 514 set of attributes (i.e., policy). 516 Other means exist. The web can be used, either through some kind of 517 search engine running based on the data at the LS, or through dynamic 518 web pages created from the LS database. This search could be 519 automated or more interactive, as is normally done with web searches. 521 Once a response is received, the end user can send its call setup 522 message to the signaling server or gateway indicated in the response. 524 The advantage of direct mode is that it gives the end user the abil- 525 ity to specify call by call policy. The policy can be arbitrarily 526 complex, depending on the services provided by the front end. The 527 disadvantage is that it requires more intelligence in the end user. 528 This may not be appropriate for embedded devices, for example. 530 6.3.2 Proxy Mode 532 In proxy mode, the end user doesn't worry about selecting or querying 533 for a gateway. The call setup message is sent to a proxy, either the 534 location server, or a signaling server which has access to the data- 535 base maintained by the LS. The LS or signaling server receives the 536 setup message, sees that it is to a gateway, and consults the data- 537 base to find the appropriate next hop signaling server or gateway to 538 terminate the call. This procedure happens transparently to the end 539 user. 541 As part of the selection process, the LS or signaling server may 542 access a policy database containing preferences specified by the end 543 user ahead of time. For example, a PC user may tell the administra- 544 tors that they would like calls towards the PSTN to be routed to 545 gateways run by provider X, or that calls should use the cheapest 546 gateway. When the LS or signaling server receives the call setup mes- 547 sage, this information can be taken into account when selecting a 548 next hop. 550 Additionally, the signaling messages may themselves contain end user 551 preferences about call routing. 553 The proxy mode front end is appropriate for thin clients, which can- 554 not express policy requirements on their own. It is also appropriate 555 when the administrator wants complete control over gateway selection. 556 It also has the advantage of making the fact that the call is a gate- 557 way call transparent to the end user. 559 7 Security Considerations 561 There are a number of security requirements. First and foremost is 562 mutual authentication between LS's which are connected. This may be 563 through either public key or shared secret. Additionally, message 564 integrity of all exchanges is required. Encryption of messages is 565 also supported. 567 As routing objects can be passed via one LS to another, there is a 568 need for some sort of end to end authentication as well. However, 569 aggregation will cause the routing objects to be modified, and there- 570 fore authentication can only take place from the point of last aggre- 571 gation to the receiving LS's. 573 8 Conclusion 575 This document has provided a framework for a gateway location proto- 576 col. The major elements, and the relationships and protocols between 577 them, have been described. 579 9 Bibliography 581 [1] International Telecommunication Union, "Visual telephone systems 582 and equipment for local area networks which provide a non-guaranteed 583 quality of service," Recommendation H.323, Telecommunication Stan- 584 dardization Sector of ITU, Geneva, Switzerland, May 1996. 586 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 587 session initiation protocol," Internet Draft, Internet Engineering 588 Task Force, Nov. 1998. Work in progress. 590 [3] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4)," 591 Request for Comments (Draft Standard) 1771, Internet Engineering Task 592 Force, Mar. 1995. (Obsoletes RFC1654). 594 [4] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, "Service 595 location protocol," Request for Comments (Proposed Standard) 2165, 596 Internet Engineering Task Force, June 1997. 598 [5] W. Yeong, T. Howes, and S. Kille, "Lightweight directory access 599 protocol," Request for Comments (Draft Standard) 1777, Internet 600 Engineering Task Force, Mar. 1995. (Obsoletes RFC1487). 602 10 Authors Addresses 604 Jonathan Rosenberg 605 Lucent Technologies, Bell Laboratories 606 101 Crawfords Corner Rd. 607 Holmdel, NJ 07733 608 Rm. 4C-526 609 email: jdrosen@bell-labs.com 611 Henning Schulzrinne 612 Columbia University 613 M/S 0401 614 1214 Amsterdam Ave. 615 New York, NY 10027-7003 616 email: schulzrinne@cs.columbia.edu