idnits 2.17.1 draft-ietf-iptel-gwloc-framework-01.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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 1998) is 9309 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 601 looks like a reference -- Missing reference section? '2' on line 606 looks like a reference -- Missing reference section? '3' on line 610 looks like a reference -- Missing reference section? '4' on line 614 looks like a reference -- Missing reference section? '5' on line 618 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPTEL WG Jonathan Rosenberg 2 Bell Laboratories 3 Henning Schulzrinne 4 draft-ietf-iptel-gwloc-framework-01.txt Columbia U. 5 October 28, 1998 6 Expires: April 28, 1999 8 A Framework for a Gateway Location Protocol 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 1 Abstract 32 This document serves as a framework for a protocol for locating an IP 33 telephony gateway. It defines terminology, specifies the various 34 architectural elements and their functions, overviews the services 35 provided by the protocol, and discusses how it fits into the broader 36 context of Internet telephony. 38 2 Introduction 40 As IP telephony gateways grow in terms of numbers and usage, managing 41 their operation will become increasingly complex. One of the diffi- 42 cult tasks is that of gateway location, also known as gateway selec- 43 tion, path selection, gateway discovery, and gateway routing. The 44 essence of the problem is that an ingress gateway or end user must 45 select a gateway to terminate a call towards the PSTN. This gateway 46 may lie in a remote administrative domain, and the selection of the 47 gateway may be based on a number of criteria. 49 To support discovery and location of gateways in remote administra- 50 tive domains, a protocol is being developed, call the Gateway Loca- 51 tion Protocol (GLP). This document serves as a framework for GLP. It 52 defines terminology used in the specification, specifies the various 53 architectural elements and their functions, overviews the services 54 provided by the protocol, and discusses how it fits into the broader 55 context of Internet telephony. 57 3 Terminology 59 We define the following terms. Note that there are other definitions 60 for these terms, outside of the context of gateway location. Our def- 61 initions aren't general, but refer to the specific meaning here: 63 oGateway: A device with some sort of PSTN connectivity and IP con- 64 nectivity, capable of initiating and terminating IP telephony sig- 65 naling protocols, and capable of initiating and terminating tele- 66 phone network signaling protocols. 68 oUser Agent (UA): An entity with IP connectivity which wishes to 69 place a call from an IP network to a user connected only via a 70 telephone network. The user agent can be an individual at a PC, an 71 intelligent IP peripheral, or a local gateway for a phone to phone 72 IP telephony call. 74 oGatekeeper: The H.323 gatekeeper element, defined in [1] 76 oSIP Server: The Session Initiation Protocol proxy server, defined 77 in [2]. 79 oSignaling Server: A signaling server is an entity which is capable 80 of receiving signaling messages for some IP telephony signaling 81 protocol, such as H.323 or SIP, and forwarding the signaling mes- 82 sages to another signaling server or gateway. Generally speaking, 83 a gatekeeper or SIP server. 85 oLocation Server (LS): A logical entity with IP connectivity which 86 has knowledge of gateways that can be used to terminate calls 87 towards the PSTN. The LS is the main entity that participates in 88 the gateway location protocol. The LS is generally a point of con- 89 tact for user agents for completing calls to the telephony net- 90 work. An LS may also be responsible for propagation of gateway 91 information to other LS's. An LS may be coresident with an H.323 92 gatekeeper of SIP server, but this is not required. 94 oAdministrative Domain: The set of gateways and Location Servers 95 under the control of a single administrative authority. User 96 agents are customers of an administrative domain. 98 oLocation Server Policy: The set of rules which dictate how a loca- 99 tion server processes information it receives via GLP. This 100 includes rules for aggregating, propagating, generating, and 101 accepting information. 103 oUser Agent Policy: Preferences that a user agent has about how a 104 call towards the PSTN should be routed. 106 4 Architecture 108 Figure 1 gives the overall architectural perspective of the gateway 109 location protocol. 111 AD1 AD2 112 ----------------- ------------------ 113 | | | | 114 | ---- | | ---- | 115 | | GW | | | | UA | | 116 | ---- \ ---- | | ---- / ---- | 117 | | LS | ---------------- | LS | | 118 | ---- ---- | / ---- \ ---- | 119 | | GW | / | /| | UA | | 120 | ---- | / | ---- | 121 | | / | | 122 ------------------ / ------------------ 123 / 124 / 125 --------- /---------- 126 | | | 127 | ---- | 128 | | LS | | 129 | / ---- \ | 130 | ---- || ---- | 131 | | GW | || | UA | | 132 | ---- || ---- | 133 | ---- || ---- | 134 | | GW | / \ | UA | | 135 | ---- ---- | 136 | | 137 --------------------- 138 AD3 140 Figure 1: GLP Architecture 142 There are a number of administrative domains (AD's), each of which 143 has at least one Location Server (LS). The LS's, through an out of 144 band means, called the intra-domain protocol, learn about the gate- 145 ways in their domain. The intra-domain protocol is represented by the 146 lines between the GW and LS elements in AD1 in the Figure. The LS's 147 have connections with other LS's, over which they exchange gateway 148 information. These connections are established administratively, and 149 are set up when the administrative domains have some kind of agree- 150 ments in place regarding exchange of gateway information. In the fig- 151 ure, the LS in AD1 is connected to the LS in AD2, which is in turn 152 connected to the LS in AD3. Through the gateway location protocol 153 (GLP), the LS in AD2 learns about the two gateways in AD1. This 154 information is accessed by user agents (UA's) in AD2 through the 155 front-end. The front-end is a non-GLP protocol or mechanism by which 156 UA's access the information. In AD3, there are both UA's and gate- 157 ways. The LS in AD3 learns about the gateways in AD1 through a poten- 158 tially aggregated advertisement from the LS in AD2. 160 The GLP is similar in flavor to inter-domain routing protocols, such 161 as BGP [3]. However, it differs in that the connectivity being 162 expressed is not network level, but represents application level 163 relationships. Furthermore, attributes play a more important role 164 here than in BGP because the protocol is an application, not network, 165 layer protocol. 167 5 Elements 169 The system for gateway location consists of a number of elements. 170 These include the administrative domain, user agent, gateway, and 171 location server. 173 5.1 Administrative Domain 175 An administrative domain consists of zero or more gateways, at least 176 one Location Server, and zero or more user agents. The gateways and 177 LS's are those which are under the administrative control of a single 178 authority. This means that there is one authority responsible for 179 dictating the policies and configuration of the gateways and LS's. 181 An administrative domain may not be the same as an autonomous system. 182 While an AS represents a set of physically connected networks, an 183 administrative domain may consist of elements on disparate networks, 184 and even within disparate autonomous systems. 186 The user agents within an administrative domain are effectively the 187 customers of that administrative domain. They are interested in com- 188 pleting calls towards the telephone network, and thus need access to 189 gateways. A user agent may be a customer of one administrative domain 190 for one call, and then a customer of a different one for the next 191 call. 193 An administrative domain may not have any gateways. In this case, its 194 LS learns about gateways in other domains, and makes these available 195 to the user agents within its domain. In this case, the administra- 196 tive domain is effectively a virtual IP telephony gateway provider. 197 This is because it provides gateway service, but may not actually own 198 or administer any gateways. 200 An administrative domain may not have any user agents. In this case, 201 it provides wholesale gateway service, making its gateways available 202 to customers in other administrative domains. 204 An administrative domain must have either gateways or user agents or 205 both. 207 5.2 Gateway 209 A gateway is a logical device which has both IP connectivity and con- 210 nectivity to some other network, usually a public or private tele- 211 phone network. The function of the gateway is to translate the media 212 and signaling protocols from one network technology to the other, 213 achieving a transparent connection for the users of the system. 215 A gateway has a number of attributes which characterize the service 216 it provides. Most fundamental among these are the range of phone num- 217 bers to which it is willing to provide service. This range may be 218 broken into subranges, and associated with each, some cost metric or 219 cost token. This token indicates some notion of cost or preference 220 for completing calls for this set of the telephone number range. 222 Question - can this actually be a dollar cost value? There are seri- 223 ous issues with trying to do this. Cost plans can be arbitrarily com- 224 plex, and be based on many different currencies. Should we provide 225 some simple cost structures (unit of currency per unit time and flat 226 rate), or just use a preference, much like a weight metric associated 227 with a route. 229 A gateway has attributes which characterize the volume of service 230 which it can provide. These include the number of ports it has (i.e., 231 the number of simultaneous phone calls it can support), and the 232 access link speed. These two together represent some notion of the 233 capacity of the gateway. The metric is useful for allowing Location 234 Servers to decide to route calls to gateways in proportion to the 235 value of the metric, thus achieving a simple form of load balancing. 237 A gateway also has attributes which characterize the type of service 238 it provides. This includes, but is not limited to, signaling proto- 239 cols supported, telephony features provided, speech codecs under- 240 stood, and encryption algorithms which are implemented. These 241 attributes may be important in selecting a gateway. In the absence of 242 baseline required features across all gateways (an admirable, but 243 difficult goal), such a set of attributes are required in order to 244 select a gateway with which communications can be established. End 245 users which have specific requirements for the call (such as a user 246 requesting a business class call, in which case certain call features 247 may need to be supported) may wish to make use of such information as 248 well. 250 5.3 User Agent 252 A user agent is an entity which wishes to complete a call through a 253 gateway from an IP network to a terminal on a telephone network. A 254 user agent may be a user logged on at a PC with some Internet tele- 255 phony software. The user agent may also be a telephone gateway, 256 dialed by a user from telephone handset. This is the case for the 257 phone to phone service using the IP network for long distance trans- 258 port. 260 User agents may, or may not be aware that there is a gateway location 261 service running when they complete a call towards the telephone net- 262 work. In cases where they are aware, user agents may have preferences 263 for how a call is completed. These preferences might include call 264 features which must be supported, quality metrics, owner or adminis- 265 trator, and cost preferences. 267 5.4 Location Server 269 The Location Server (LS) is the main functional entity of the gateway 270 location protocol. It is a logical device which has access to a data- 271 base of gateways, and participates in the gateway location protocol. 272 As a participant, its job is to receive information about gateways 273 from other Location Servers, send information to other Location 274 Servers about gateways it knows about, and to aggregate and forward 275 information about gateways to other LS's. 277 The database built up in the LS allows it to make decisions about IP 278 telephony call routing. When a signaling message arrives at a signal- 279 ing server, destined for a telephone network address, the LS's 280 database can provide information which is useful for determining a 281 gateway or an additional signaling server to forward the signaling 282 message to. For this reason, an LS may be coresident with a signaling 283 server. 285 An LS is a representative for an administrative domain. An adminis- 286 trative domain must have at least one LS in order to participate in 287 the gateway location protocol. An administrative domain may have more 288 than one LS, for purposes of load balancing, ease of management, or 289 any other reason. 291 One or more of the LS's in an administrative domain may have knowl- 292 edge of the gateways run by the administrative domain. This knowledge 293 may be configured statically, learned through other protocols, or 294 acquired through gwloc by placing an LS coresident with the gateway, 295 allowing the gateway to participate in gwloc. 297 The information learned from other LS's may be used by an LS to aid 298 in routing calls which originate or transit through the administra- 299 tive domain. 301 A LS may be coresident with an H.323 gatekeeper, SIP server, or MGCP 302 call agent, but this need not be the case. When they are not coresi- 303 dent, some means of communication between the LS and the server, 304 gatekeeper, or call agent is needed. This communication is not 305 addressed by the gwloc protocol. 307 6 Element Interactions 309 6.1 Gateways and Location Servers 311 Gateways must somehow propagate information about their characteris- 312 tics to an LS which will further propagate this information. That LS 313 is called an originating LS for that gateway. When an LS is not 314 coresident with the gateway, the means by which the information gets 315 propagated is not within the scope of the gateway location protocol. 316 The protocol used to accomplish this is generally called an intra- 317 domain protocol. 319 One way in which the information can be propagated is with the Ser- 320 vice Location Protocol (SLP) [4]. The gateway can contain a Service 321 Agent (SA), and the LS can act as a Directory Agent (DA). SLP defines 322 procedures by which service information is automatically propagated 323 to DA's from SA's. In this fashion, an LS can learn about gateways in 324 the administrative domain. 326 An alternate mechanism for the intra-domain protocol is via the reg- 327 istration procedures of SIP or H.323. The registration procedures 328 provide a means by which users inform a gatekeeper or SIP server 329 about their address. Such a registration procedure could be extended 330 to allow a gateway to effectively register as well. 332 Other means exist as well. These might include LDAP [5], email, web 333 page, or human based means, such as a phone call or letter. The mech- 334 anism which is used may be different from administrative domain to 335 administrative domain, and is a matter of local configuration. The 336 only requirement for the gateway location protocol to operate effec- 337 tively is that this mechanism exist in some form. 339 6.2 Location Server to Location Server 341 The interaction between LS's is what is defined by the gateway loca- 342 tion protocol. 344 LS's communicate with each other through TCP connections. An LS may 345 be connected to one or more other LS's. LS's need not be physically 346 adjacent or part of the same autonomous system. The TCP connection 347 between a pair of LS's is set up administratively. There is no 348 autodiscovery procedure. Two LS's are configured to communicate with 349 each other when their administrators have an agreement in place to 350 exchange gateway information. The syntax and semantics of the mes- 351 sages exchanged over this connection are dictated by the gateway 352 location protocol. The protocol does not dictate the nature of the 353 agreements which must be in place, nor does it dictate what informa- 354 tion is actually exchanged. The gwloc protocol merely provides a 355 transport means to exchange whatever information is deemed appropri- 356 ate by the administrators of the system. 358 The rules which govern which gateway information is generated, propa- 359 gated, and accepted by a gateway is called a location server policy. 360 The gateway location protocol does not dicate or mandate any specific 361 policy. 363 When an LS learns about a gateway through some means outside of the 364 gateway location protocol, and then propagates this information to 365 other LS's through the gateway location protocol, that LS is said to 366 be an originating LS for that gateway. This means that the LS is the 367 one responsible for determining when an update about the gateway 368 should be sent. 370 Two LS's may be connected even if they are owned by the same adminis- 371 trative authority. This may be done for a number of reasons. First, 372 an LS may be coresident with a gateway. As a result, this LS will 373 have knowledge about the state of the gateway, whether it is up or 374 down, and whether any attributes have changed. Thus, this LS is an 375 originating LS for the gateway it is coresident with. By connecting 376 this LS with other LS's in the administrative domain, other LS's can 377 learn about gateways within the administrative system. Second, an 378 administrative domain may have multiple LS's for purposes of scala- 379 bility and load balancing. These may communicate with each other in 380 order to maintain a consistent database of gateways. 382 6.2.1 Nature of Exchanged Information 384 The information exchanged by the LS's is a set of gateway objects. 385 Each gateway object minimally consists of a range of telephone num- 386 bers which are reachable, and an IP address which is the next hop 387 towards a gateway which can reach that range. In the case of an LS 388 coresident with a gateway, this address will be its own address, and 389 the address range is the set of addresses which it can complete calls 390 to. This information is then sent from the gateway (through its 391 coresident LS) to another LS. This LS, in turn, may receive adver- 392 tisements from other LS's. An LS may aggregate this information 393 together, merging ranges of telephone numbers, and replacing the IP 394 address with its own IP address, or with the IP address of a signal- 395 ing server with which the LS is communicating. 397 Consider a simple example of two gateways, A and B, capable of reach- 398 ing some set of telephone numbers, X and Y, respectively. A and B are 399 each coresident with an LS. Both A and B are connected to C. A sends 400 C a gateway object containing range X, and IP address A. B sends C a 401 gateway object containing range Y, and IP address B. C aggregates 402 these together. As it turns out, X and Y can be combined into a sin- 403 gle address range, Z. C therefore sends a single gateway object to 404 one of its peers, D, containing address range Z and its own address, 405 since it is also a signaling server. D is also a signaling server. 407 Some client, E, wishes to place a phone call to telephone number T, 408 which happens to be in the address range X. E is configured to use D 409 as its default H.323 gatekeeper. So, E sends a call setup message to 410 D, containing destination address T. D determines that the address T 411 is within the range Z. As D had received a gateway object from C con- 412 taining address range Z, it forwards the call setup message to C. C, 413 in turn, sees that T is within range X, and so it forwards the call 414 setup to A, which terminates the call signaling and initiates a call 415 towards the telephone network. 417 A gateway object may have additional information which characterizes 418 the service at the gateway. These attributes include things like pro- 419 tocols, features supported, capacity, and cost metrics. 421 Aggregating advertisements together which contain these attributes is 422 nearly impossible. As a result, an LS must either pass the entire 423 gateway object unmodified, or, it it aggregates the gateway 424 information together, remove the additional information before propa- 425 gating it. 427 6.2.2 Determining when to send an object 429 An LS is free to send an updated gateway object at its discretion. 430 Normally, an update is sent if (1) the LS is an originating LS, and 431 the attributes or state of the gateway has changed, (2) the LS has 432 received an updated object, and wishes to propagate it or change 433 other objects which it created as a result of aggregation, (3) the 434 policy of the LS has changed. 436 6.3 User Agents and Location Servers 438 The interaction between the user agents and location servers is also 439 outside the scope of the gateway location protocol. This interaction 440 is referred to as the front-end, as it provides the visible means by 441 which the gateway location protocol services are exposed. 443 A front end is required when an administrative domain has user 444 agents, and these user agents wish to complete calls to a telephone 445 network address. This can happen when a user sitting at a PC types a 446 telephone number into their IP telephony software, or when an ingress 447 gateway receives a call from a telephone wishing to complete a call 448 to another telephone. In both cases, the user agent must determine 449 where to send its signaling messages in order to complete the call. 451 In some cases, the user agent may have requirements about how they 452 would like the call to be routed. These include preferences about 453 cost, quality, administrator, or call services and protocols. These 454 requirements are called the user agent policy. This policy is dis- 455 tinct from the location server policy. The location server policy 456 includes the providers preferences about which gateways to accept and 457 make available to its customers: the user agents in its administra- 458 tive domain. The location server policy effectively takes the set of 459 all available gateways, and distills them into a list which is 460 acceptable to the provider. The user agent policy may then be used to 461 select among those gateways. When a user agent policy is expressed, 462 it is the discretion of the administrator whether to use or modify 463 this policy when selecting a gateway. 465 There are two models for the front end. These are called direct and 466 proxy modes. 468 6.3.1 Direct Mode 470 In direct mode, the user agent is aware that the call needs to termi- 471 nate on the telephone network, and it directly queries one of the 472 LS's within the administrative domain for the address of a gateway or 473 signaling server which can route the call. This query can contain 474 policy from the user agent, or can just contain the telephone number 475 which is desired. The LS receives the query, and after consulting its 476 database, and any existing policy, returns zero or more addresses to 477 the user agent. The response to the user agent may also contain 478 parameters or attributes of the gateway if they are known. 480 Many protocols may be used for direct mode access. The Service Loca- 481 tion Protocol (SLP) is one example; its been designed to fit exactly 482 this kind of need. The user agent is an SLP UA, and the LS is an SLP 483 DA. The Service Query is used to ask for a gateway with a particular 484 set of attributes (i.e., policy). 486 Other means exist. The web can be used, either through some kind of 487 search engine running based on the data at the LS, or through dynamic 488 web pages created from the LS database. This search could be auto- 489 mated or more interactive, as is normally done with web searches. 491 Once a response is received, the user agent can send its call setup 492 message to the signaling server or gateway indicated in the response. 494 The advantage of direct mode is that it gives the user agent the 495 ability to specify call by call policy. The policy can be arbitrarily 496 complex, depending on the services provided by the front end. The 497 disadvantage is that it requires more intelligence in the user agent. 498 This may not be appropriate for embedded devices, for example. 500 6.3.2 Proxy Mode 502 In proxy mode, the user agent doesn't worry about selecting or query- 503 ing for a gateway. The call setup message is sent to a proxy, either 504 the location server, or a signaling server which has access to the 505 database maintained by the LS. The LS or signaling server receives 506 the setup message, sees that it is to a gateway, and consults the 507 database to find the appropriate next hop signaling server or gateway 508 to terminate the call. This procedure happens transparently to the 509 user agent. 511 As part of the selection process, the LS or signaling server may 512 access a policy database containing preferences specified by the user 513 agent ahead of time. For example, a PC user may tell the administra- 514 tors that they would like calls towards the PSTN to be routed to 515 gateways run by provider X, or that calls should use the cheapest 516 gateway. When the LS or signaling server receives the call setup mes- 517 sage, this information can be taken into account when selecting a 518 next hop. 520 Additionally, the signaling messages may themselves contain user 521 agent preferences about call routing. 523 The proxy mode front end is appropriate for thin clients, which can- 524 not express policy requirements on their own. It is also appropriate 525 when the administrator wants complete control over gateway selection. 526 It also has the advantage of making the fact that the call is a gate- 527 way call transparent to the user agent. 529 7 Security Considerations 531 There are a number of security requirements. First and foremost is 532 mutual authentication between LS's which are connected. This may be 533 through either public key or shared secret. Additionally, message 534 integrity of all exchanges is required. Encryption of messages is 535 also supported. 537 As gateway objects can be passed via one LS to another, there is a 538 need for some sort of end to end authentication as well. However, 539 aggregation will cause the gateway objects to be modified, and there- 540 fore authentication can only take place from the point of last aggre- 541 gation to the receiving LS's. 543 8 Conclusion 545 This document has provided a framework for a gateway location proto- 546 col. The major elements, and the relationships and protocols between 547 them, have been described. 549 9 Open Issues 551 oExpression of cost. Can or should we express cost structures in 552 the gateway advertisements? 554 oAggregation. The draft proposes that all attributes except tele- 555 phone number range and next hop be hop-by-hop attributes, and 556 shouldn't be propagated unless the advertisement is transparently 557 propagated (that is, not aggregated or de-aggregated). Is this the 558 right approach? Is there some middle ground here? Need we even 559 specify rules such as this? 561 oPath qualification. There is nothing in here about what has been 562 called path qualification. That is, does a path between two sig- 563 naling servers or LS's actually exist, and if so, does it have 564 sufficient quality to carry the call? This is tough, as it strays 565 within the realm of QoS routing and differentiated services, which 566 is out of scope. 568 oAttributes. What attributes should be allow for a gateway? 570 10 Full Copyright Statement 572 Copyright (C) The Internet Society (1998). All Rights Reserved. 574 This document and translations of it may be copied and furnished to 575 others, and derivative works that comment on or otherwise explain it 576 or assist in its implmentation may be prepared, copied, published and 577 distributed, in whole or in part, without restriction of any kind, 578 provided that the above copyright notice and this paragraph are 579 included on all such copies and derivative works. 581 However, this document itself may not be modified in any way, such as 582 by removing the copyright notice or references to the Internet Soci- 583 ety or other Internet organizations, except as needed for the purpose 584 of developing Internet standards in which case the procedures for 585 copyrights defined in the Internet Standards process must be fol- 586 lowed, or as required to translate it into languages other than 587 English. 589 The limited permissions granted above are perpetual and will not be 590 revoked by the Internet Society or its successors or assigns. 592 This document and the information contained herein is provided on an 593 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 594 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 595 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 596 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 597 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 599 11 Bibliography 601 [1] International Telecommunication Union, Visual telephone systems 602 and equipment for local area networks which provide a non-guaranteed 603 quality of service, Recommendation H.323, Telecommunication Standard- 604 ization Sector of ITU, Geneva, Switzerland, May 1996. 606 [2] M. Handley, H. Schulzrinne, and E. Schooler, SIP: session initia- 607 tion protocol, Internet Draft, Internet Engineering Task Force, May 608 1998. Work in progress. 610 [3] Y. Rekhter and T. Li, A border gateway protocol 4 (BGP-4), 611 Request for Comments (Draft Standard) 1771, Internet Engineering Task 612 Force, Mar. 1995. (Obsoletes RFC1654). 614 [4] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, Service loca- 615 tion protocol, Request for Comments (Proposed Standard) 2165, 616 Internet Engineering Task Force, June 1997. 618 [5] W. Yeong, T. Howes, and S. Kille, Lightweight directory access 619 protocol, Request for Comments (Draft Standard) 1777, Internet Engi- 620 neering Task Force, Mar. 1995. (Obsoletes RFC1487). 622 12 Authors Addresses 624 Jonathan Rosenberg 625 Lucent Technologies, Bell Laboratories 626 101 Crawfords Corner Rd. 627 Holmdel, NJ 07733 628 Rm. 4C-526 629 email: jdrosen@bell-labs.com 631 Henning Schulzrinne 632 Columbia University 633 M/S 0401 634 1214 Amsterdam Ave. 635 New York, NY 10027-7003 636 email: schulzrinne@cs.columbia.edu