INTERNET-DRAFT C. Agapi Noverber 18, 1998 C. Chiu Expires: May 18, 1999 T. Chong H. Phillips B. Willingham Information Networking Institute, CMU Internet Telephony Gateway Location Service Protocol draft-agapi-ini-gwloc-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The development of IP to PSTN gateways has made it possible for users of the two disparate networks to place 'telephone' calls between the two networks with little effort. Users placing calls from an IP network to the PSTN network must choose a gateway to act as a bridge between the two networks. Selection of a gateway can be based on any number of criteria, such as price, codecs, version, billing, etc. In this draft we propose a gateway location service for this purpose. The gateway location service protocol is an instantiation of the Service Location Protocol that has been modified to run in a wide area network across many administrative domains. Table of Contents 1. Introduction ................................................... 2 Agapi, Chiu, Chong, Phillips, Willingham INI[Page 1] Internet-Draft Gateway Location Service Protocol November 1998 1.1. Literature Review ............................................ 3 2. Overview of the Protocol ....................................... 4 2.1. Interaction of Clients with Gateway Location Servers ......... 5 2.2. Interaction of Gateways with Gateway Location Servers ........ 6 2.2.1. Possible Attributes ........................................ 7 2.3. Interactions between Gateway Location Servers ................ 9 2.4. Business Models ............................................. 10 3. Features of the Protocol ...................................... 11 3.1. Scalability ................................................. 11 3.2. GLS Service Load and Caching ................................ 14 3.3. Thrashing ................................................... 15 4. Overview of SLP ............................................... 16 4.1. Gateway Location Service as an SLP Service .................. 17 4.1.1. Protocol Overview ......................................... 17 4.1.2. Structure of Required GLSP Messages ....................... 20 4.1.2.1. SLP Message Header ...................................... 20 4.1.2.2. Service Request ......................................... 21 4.1.2.3. Service Reply ........................................... 23 4.1.2.4. Service Registration .................................... 22 4.1.2.5. Service Acknowledgment .................................. 25 4.1.2.6. Service Update .......................................... 25 4.1.2.7. Directory Agent Advertisement ........................... 25 4.1.2.8. Zone Transfers .......................................... 26 4.2. Modified SLP Messages ....................................... 26 4.2.1. Using XML for Service Registration ........................ 27 4.2.2. Attributes Descriptions ................................... 28 4.2.3. Extended URL for Service Reply ............................ 32 5. Security Considerations ....................................... 33 6. Conclusion .................................................... 35 7. Abbreviations ................................................. 36 8. Acknowledgments ............................................... 36 9. References .................................................... 37 1. Introduction Traditional phone service uses a circuit switched network referred to as the public switched telephone network or PSTN. For a call to be established in this network, a path from the caller to the callee must be reserved. This reserved connection consumes a constant bandwidth of 64kbps along the path between the users. IP telephony is fundamentally different because it uses a packet switched network architecture. Calls can be established using reliable TCP connections, and voice signals can be transmitted using unreliable protocols like UDP. Our purpose here is not to argue the pros and cons of these two architectures, but to stress the importance of being able to make calls between the two networks. Agapi, Chiu, Chong, Phillips, Willingham INI[Page 2] Internet-Draft Gateway Location Service Protocol November 1998 In the recent past, IP telephony devices could only be used to place calls to other users who operated similar IP devices. Similarly, standard phones could only be used to call other users connected to the PSTN. Fortunately, the need for interoperability was realized and Gateways were developed that could connect the two networks. These IP to PSTN Gateways act as protocol converters that can extract encoded voice from an IP packet and transmit the signal as a standard PSTN voice call. The Gateway can of course packetize PSTN signals into IP packets also. The PSTN currently carries a vast majority of telephony traffic. To achieve widespread use of Internet telephony, there must be seamless interoperability between the two networks. One difficulty in connecting the two networks is defining a name or number for calling IP devices. This problem is being handled by other groups and is frequently referred to as the "E.164 number resolution problem", because they are trying to associate telephone numbers (defined by ITU standard E.164) with Internet standard IP addresses. One solution that is being examined is to designate a special country code for use by IP telephony devices [1]. Another approach is to use some sort of directory service, such as DNS, to lookup an E.164 number and return the associated IP address [2]. This paper discusses what happens when an IP telephony user wants to place a call to a PSTN user. We define a gateway location service protocol so IP telephony users can find suitable gateways for completing calls. 1.1. Literature Review In the IETF draft "A Framework for a Gateway Location Protocol (GLP)" [3], the proposed protocol defines a location server (LS) for assisting the setup of Internet telephony calls. Location servers and gateways are grouped into administrative domains and gateway information may be propagated between location servers. Each location server maintains a database of information about gateways, which it can forward to other location servers. Every gateway is defined to have an originating location server. The paper proposes the use of the Service Location Protocol (SLP) for obtaining information about gateways that are coresident with location servers [4]. Location servers exchange gateway information, also called gateway objects, amongst themselves. Each object contains at least a range of reachable telephone numbers and a next hop IP address. Additional information such as features supported, capacity, protocols, and cost metrics may also be part of the gateway object. In the paper "Internet Telephony Gateway Location", Rosenberg and Agapi, Chiu, Chong, Phillips, Willingham INI[Page 3] Internet-Draft Gateway Location Service Protocol November 1998 Schulzrinne introduced the Brokered Multicast Advertisements (BMA) protocol architecture [5]. The BMA architecture is similar to the Service Location Protocol (SLP), but is applied specifically to the problem of gateway location over a wide area network. The main benefits of IP telephony as compared to PSTN, are better user interfaces, flexible integration with other tools such as web browsers and personal mobility. If situated at the Network layer, a gateway translates routing and addressing information. Application layer gateways behave as end systems on both the IP and PSTN networks. The issue of gateway location has often been compared to DNS server location over the Internet. However, the nature of the services provided by an IP gateway make such a comparison inappropriate, because a DNS server relies on static configuration while choosing an appropriate gateway involves dynamic variables such as cost, blocking probability, and billing support. Whereas there are no per-access charges associated with DNS lookups, there is a cost associated with completing the call. Locating an IP gateway as close to the PSTN callee as possible thus makes sense as this would make the cheapest cost passed on to the client. In other cases, an end user may opt for the best quality possible. Thus, a good gateway location protocol must be dynamic, distributed, bandwidth efficient, scalable, open to competitive business environments, and secured. The pros and cons of several possible solutions are discussed in the BMA paper. From these considerations, BMA emerges as a hybrid, scalable and robust mechanism. The BMA architecture is composed of a client and a broker (whose role is similar to that of a Directory Agent in SLP). Brokers are grouped into multicast groups, collecting announcements and storing them in local databases. The BMA model makes use of scalable wide area multicasting for gateway advertisements. The broker handles the collection, storage and processing of advertisements. This minimizes lookup delays and allows rapid updates of advertisements. Multicast groups can be grouped according to country codes or selection policies. Based on any criteria, a broker can selectively drop advertisements from certain gateways. Such policy-based selection is not possible with single database storing. The main limitation of the BMA is the number of records to be searched. To maintain scalability, the size of the database must be restricted or they must be distributed. 2. Overview of the Protocol Before the Gateway Location Service is used the IP telephony user Agapi, Chiu, Chong, Phillips, Willingham INI[Page 4] Internet-Draft Gateway Location Service Protocol November 1998 must know the E.164 number of the user she is calling. We then assume that the IP telephony program she is running has discovered from the resolution phase whether the call is going to an IP or PSTN endpoint. In the trivial case where the number being called maps to an IP address, the call will be set up using IP to IP protocols. In the latter case where the number being called is for a PSTN endpoint the program must invoke a protocol to look-up a directory service provider that knows of all the available gateways. In the Gateway Location Service protocol there are three types of devices: clients (endpoints and Gatekeepers), Gateways, and Gateway Location Servers. The ITU-T has defined the H.323 standard for setting up calls between endpoints and gateways [6]. However, there is currently no standard describing how endpoints are supposed to find gateways. The following sections outline the Gateway Location Service, a protocol for keeping track of gateways. We will first describe the requirements for interaction between endpoints and GLSs. Second we will discuss the communications between Gateways and a GLSs. Finally, we briefly discuss the benefits of having a protocol for communication between multiple Gateway Location Servers. 2.1. Interaction of Clients with Gateway Location Servers Any call that starts on the Internet but ends on the PSTN must use a gateway to convert between the disparate protocols. To discover which gateway is best suited for an individual call the device originating the call must become a client of the Gateway Location Service. Common examples of such devices include computer telephony programs, IP phones, and H.323 gatekeepers. While computer telephony devices and gatekeepers have large amounts of memory and processing power, most IP telephones are relatively simple, scaled-down devices. For this reason, some IP telephones might rely on Gatekeepers to represent them to Gateway Location Servers. Doing so would ease the burden on IP telephones and might also lead to scalability benefits by allowing caching at the Gatekeeper level. When a user places a call from an IP phone he should not need to know if the person he is calling uses an IP telephony device or a PSTN phone. There are many organizations currently working on developing this transparency, which is often referred to as E.164 resolution [1, 2, 7]. The idea is that the number will be sent to a system that will determine if the end device is an IP or PSTN device. In the former case the call can be completed between the endpoints directly and in the latter case the call setup will be passed to a Gateway Location Server. Once it has been determined that the call must go though a gateway there are many questions the caller might ask the gateway before a Agapi, Chiu, Chong, Phillips, Willingham INI[Page 5] Internet-Draft Gateway Location Service Protocol November 1998 connection can be established, such as: "what codecs do you support?" or "what price will you charge me to reach the number and how do you accept payment?" If a caller had to query every gateway for answers to these questions at the start of every call he would have to wait an unreasonable amount of time and would be causing wasteful network traffic. It would be much better if there existed an omniscient device that the caller could contact and say: "you know everything about every gateway so tell me which one can complete my call using codec g.711 at the lowest cost?" The Gateway Location Service, while not omniscient, is designed to be able to answer queries from clients with current information about which gateways are available for the job. It is important to return results to the client quickly since further call setup between the client and the gateway is necessary before the call can begin. A client must be able to verify the authenticity of the GLS that is returning the results of its query. This will allow the client to make sure the results are coming from a trusted entity. If authentication is not used, a malevolent GLS operator could take advantage of the customer in many ways. An easy to image scheme would be to guide calls to an expensive gateway while claiming it is the least expensive gateway available. 2.2. Interaction of Gateways with Gateway Location Servers The protocol above describes in general terms the dissemination of knowledge from the gateway location server to the endpoints. This section discusses the assimilation of that knowledge from the individual gateways. Every gateway should talk to every GLS to ensure state consistency across the system. Although the GLSs can communicate with each other, as explained in the next section, it is better for each gateway to talk with all of them. If the GLS is run on the public Internet, GLSs should accept information from all gateways. To do otherwise could end in unfair treatment of some gateways. For this reason, GLSs are not allowed to aggregate or delete any records that they receive. It is therefore very important that the information within the records sent by gateways be compact. For example, a gateway serving only one area code should send a single price for all calls that match that area code instead of sending ten million phone numbers all showing the same price. The concept of a gateway as a distributed entity, consisting of a gateway controller and various media gateways has also been introduced [8]. The gateway controller will present itself to the GLS as a single gateway, but will in fact be representing the pooled resources of any number of media gateways. This was designed for Agapi, Chiu, Chong, Phillips, Willingham INI[Page 6] Internet-Draft Gateway Location Service Protocol November 1998 gateways within a single administrative domain so that the underlying network deployment would not be obvious to other system providers and for aggregation. It is acceptable for a gateway controller to aggregate and delete information about the media gateways that it represents because doing so does not defeat the interests of other providers. The use of gateway controllers in the GLS system has a beneficial effect on the scalability of the protocol. Gateway controllers function as a single point of contact for a large number of media gateways, simplifying the communication of gateway information. The total amount of information sent to the GLSs will be approximately the same, but the number of transmissions will be reduced. There could also be a reduction in the amount of information if the gateway controller uses aggregation or policy to reduce the information. For example, a gateway controller representing fifty media gateways that are dispersed across the United States could send a single record for calls to the US country code rather than fifty separate records. This reduction in information simplifies the records stored in the GLSs, which improves the speed of searches. Opportunities for caching are also greatly enhanced when a single gateway controller can reach a large number of phones via its gateways. It is extremely important that this portion of the protocol be highly secure because it directly effects the revenue of operating gateways. If the protocol was left insecure, an attacker could distribute false pricing information causing calls to be directed away from a gateway thus eliminating any revenue for that provider. Encryption of the records being sent is not necessary since that information will be publicly available from the gateway location service. However, methods of authorizing gateways and of authenticating records are necessary. The information that describes a gateway, such as domain name, supported codecs, and signaling protocols, is relatively stable. Because of this, the amount of information that needs to be sent to the GLSs on a periodic basis is minimal. When the first contact between a gateway and a GLS is made all of these nonvolatile attributes will be stored at the GLS. After the gateway is entered in the GLS's database, the gateway will continue to send periodic updates with information about projected blocking probabilities and changes in prices. Gateways are responsible for sending this information to the GLSs. GLSs may advertise themselves to gateways, but are not allowed to request information from them. 2.2.1. Possible Attributes The Gateway Location Service selects appropriate gateways for clients Agapi, Chiu, Chong, Phillips, Willingham INI[Page 7] Internet-Draft Gateway Location Service Protocol November 1998 based on attribute information. The common ground is that these attributes must be gateway-specific. Most of the potential attributes discussed here were first introduced in the gwloc framework paper [3]. However, we present a slightly different set of possible attributes with corresponding justifications. Identifier of Gateway: This will be the ID of the gateway service provider. Some possible identifiers are IP address, DNS domain name, or an ASCII string. Using an IP address as the identifier is not a good idea since a gateway may have more than one IP appearance. An X.400 Distinguished Name as it appears in the gateway's X.509 public key certificate may be the most appropriate choice, since this ID can be used to authenticate identity. Signaling Protocol: There are many protocols, such as H.323 and SIP, which may be used in setting up calls between endpoints and gateways. Including this attribute allows endpoints to find only gateways with which they share a common protocol. Point of Contact: The point of contact often varies between protocols. In the H.323 protocol the contact address could be a gatekeeper representing a gateway. In the SIP protocol the point of contact might be the terminating gateway itself. The point of contact format could be a transport address or a URL. An explicit IP listing is preferred since clients could avoid querying a DNS for IP resolution during call setup, hence shortening the call setup time. Autonomous System of Gateway: This is the BGP AS number of the network the gateway is located on [9]. This attribute would likely be used when some inference could be made about the expected path quality based upon the AS of the caller and the gateway. Quality of Service Capability: This attribute indicates what quality of service protocols are supported by the gateway's ITSP. Some possibilities are RSVP, diffserv, other bandwidth reservation protocols or methods of providing virtual circuits. Payment Method: If gateways are to be used for carrying public traffic, they will likely need a method of collecting money from their users. This attribute is a business issues and thus should not be strictly specified by the protocol. It should allow gateways to offer clients the choice of per-usage billing using credit cards or electronic cash, or possibly the client would set up a billing account in the gateway's administrative domain ahead of time. E.164 Prefix: The phone number prefixes that the gateway can reach. The gateway location service will use maximum prefix matching to search its database and return appropriate results. Agapi, Chiu, Chong, Phillips, Willingham INI[Page 8] Internet-Draft Gateway Location Service Protocol November 1998 Blocking Probability: This parameter provides clients a way to know the probability of the gateway refusing a call because all its lines are busy. Clients can then make calls based on port availability of the gateway. Unlike the gwloc framework which uses total and available line probability, we define blocking probability as the probability that not all trunks of the gateway are occupied during a period of time. Defining the blocking probability this way allows providers to keep the information about the capacity of their network private. The averaging period used in calculating the blocking probability should be short enough to provide useful state information, but long enough to prevent excessive network traffic and possible thrashing problems. Price: Price defines the charges assessed by the gateway provider per call. The gateway location service should allow gateways to update their pricing plans at any time. This allows for dynamic pricing, but the protocol also allows for the caching of gateway records to improve scalability. The time between price updates and the usefulness of caches is positively correlated, so implementers should choose update intervals carefully. Codecs Supported: This attribute indicates what codecs are supported by a given prefix within a gateway. Features Supported: The features supported attribute would hold information about telephony services above basic call connection that a gateway could perform, such as call forwarding or conference calling. Confederation: Memberships in various confederations or clearinghouses. Proximity: Proximity allows a caller to choose a gateway near to herself, instead of near the callee. The issue here is picking a gateway so the caller can make the best quality phone calls. Shortening the geographic distance from the caller to the gateway does not guarantee performance, the hop-counts between them and bandwidth among interconnections set the result. We leave this issue alone since these are not properties of the gateway but of the caller-gateway pair, and as such can not readily be represented in a gateway location server. 2.3. Interactions between Gateway Location Servers Allowing gateway location servers to communicate among one another speeds the propagation of state through out the system. For example, when a new GLS comes online it can request a full transfer from another GLS, instead of building its' own database from communication Agapi, Chiu, Chong, Phillips, Willingham INI[Page 9] Internet-Draft Gateway Location Service Protocol November 1998 with gateways. This feature is also useful for gatekeepers or other GLS clients that operate as aggregation services. They can request a full transfer of a GLS's records, but parse out and discard records that do not match their criteria. This allows them to keep a complete cache of gateways that meet their requirements without maintaining direct communication with the gateways. Domain Name Servers have a similar method of divulging information via zone transfers. A zone transfer from a functioning GLS to a new GLS acts as a snapshot of the current state. If the new GLS wants to remain current, it must actively seek information from gateways. The easiest way for this to happen is for the new GLS to advertise itself to each gateway that was mentioned in the zone transfer. Thus a GLS starting from scratch can quickly and efficiently begin servicing client queries. The requirements for security of this portion of the protocol parallel those described in the previous section. 2.4. Business Models Different business models affect the interactions among all elements involved in a gateway location service protocol. Moreover, business model dominates the successful implementation of a gateway location service protocol. We do not know what kind of business models will be actually used, so we briefly discuss possible models and related issues here. Gateway service providers may form coalitions. In this model there is not much interaction between GLSs. Each GLS would contain only a set of gateway information come from the coalition to which it belongs. So there will be limited choices left for end users or their agents to make further decisions. The GLS could decide a single 'best' gateway for its users. The amount of network traffic can be largely reduced, and total response time is also shortened. The function of GLS becomes less important in this model, and service providers could even design proprietary protocols for their own use. Another model is to treat GLSs as Clearinghouses. Every GLS will provide services to users in its own domain, then exchange its information with other GLSs periodically. The gateway location problem is concentrated on GLS interactions in this model. The interactions among GLSs could be something like the Network News Transport Protocol, or DNS zone transfer. It is possible that users and GLSs would be unable to get timely information, such as blocking probability, and will not be able to respond to dynamic gateway price updates. This model is similar to the one described in the gwloc Agapi, Chiu, Chong, Phillips, Willingham INI[Page 10] Internet-Draft Gateway Location Service Protocol November 1998 framework [15]. There can also be many administratively independent gateway domains. Companies may prefer to run GLSs on their own. In this model the number of GLSs is large and the network traffic between GLS and gateway domains are heavy, hence multicast capabilities such as described in BMA [5] is required. Since user base is reduced, GLS could provide more heavy-load services for their clients, such as sorting out a best gateway based on different criteria. 3. Features of the Protocol This section is an overview of some problems that may be faced by the implementers of this protocol. The Gateway Location Service, an extension of the Service Location Protocol, is designed to work in a wide area network. However, SLP was originally designed to run on Local Area Networks under a single administrative domain. The sections on scalability and caching discuss the benefits and drawbacks of expanding SLP to a WAN environment. The GLS protocol is designed so that endpoints can select gateways based on specific criteria, such as price or codec. GLS also allows gateways to update those attributes frequently. There is potential for thrashing to occur if one of the attributes, price for instance, becomes the dominant selection attribute in endpoint queries. If all endpoints requested the lowest cost gateway, that gateway would soon run out of capacity and start blocking calls. At this point all the calls would be routed to the next lowest cost gateway that has a lower blocking probability. The section on thrashing and update intervals further explains this problem. 3.1. Scalability The GLS protocol is meant to be an open standard, which may be implemented and operated by anyone. It is likely that the same people who operate gateways, which today includes ISPs, Corporations, CLECs, ILECs, and IXCs will run Gateway Location Servers. Carriers of IP or PSTN traffic will be the most likely GLS providers. The number of gateways being tracked by the protocol is also highly dependent on the entities running the gateways. Corporations are likely to have private gateways that they operate the same as PBX systems. These gateways would represent a small number of phones, but there would be many of them. ILECs and IXCs would run carrier grade gateways that could handle hundreds of thousands of simultaneous calls. If carriers use gateway controllers to represent their networks, a single gateway controller might represent millions of phone numbers. The issues of who will run gateways and how many they will run are difficult to quantify, so the following argument is Agapi, Chiu, Chong, Phillips, Willingham INI[Page 11] Internet-Draft Gateway Location Service Protocol November 1998 based upon available calling statistics obtained from the FCC. When talking about gateways, it is important to remember that they are merely bridges between the PSTN and IP networks. This means that gateways will never be responsible for carrying one hundred percent of call traffic. Lets consider the four possibilities of origination-destination pairs; IP-IP, IP-PSTN, PSTN-IP, PSTN-PSTN. Current call patterns place a huge majority of calls in the PSTN-PSTN category, but IP traffic is becoming more popular. For the sake of this argument, we will assume that all calls will eventually be IP- IP. In the transition from the PSTN-PSTN dominated call scenario to the IP-IP dominated call scenario, there will be a point where the IP and PSTN networks carry the same number of calls per year. At this point gateways will be responsible for carrying at most fifty percent of all calls. The graph shown in Figure 1 below illustrates gateway use assuming that the likelihood that a caller from an IP (PSTN) phone wishes to reach a callee on the IP (PSTN) network is proportional to the fraction of all phones that are IP (PSTN) respectively. The maximum number of calls that gateways will have to handle per year can be predicted by making assumptions about the growth of overall traffic and the growth of IP traffic. If use the statistic that world wide call traffic increases by 12.1% percent per year and assume that IP traffic will match PSTN traffic in fifteen years, we can predict the maximum calls that must be handled by the gateways to be around 6.25 trillion calls per year [10]. This assumes current call levels of 2.25 trillion calls per year, and uses the argument that at most fifty percent of calls will require gateways. If we use an average call length of three minutes, there will be close to 12 million calls proceeding at any given time. To compensate for the higher volume of calls during busy times of day this number should be multiplied by 5, giving 60 million simultaneous calls. The number of gateways and Gateway Location Servers required to handle this volume of calls can be found with only a few more assumptions. If the average capacity of a gateway is 500 calls, then there will be at most 120 thousand gateways. Many of those will be small corporate gateways and some will be very large carrier gateways. The number of Gateway Location Servers will likely be proportionate to this number, but the exact ratio will vary over time. For this example, we assume a ratio of one GLS for every fifty gateways, giving 2400 GLSs. These numbers represent the estimated upperbound for the number of gateways and GLSs. If we look more closely at our assumption about which network calls terminate on, we will see that the percentage of calls requiring a gateway will never reach 50%. This is because of a Agapi, Chiu, Chong, Phillips, Willingham INI[Page 12] Internet-Draft Gateway Location Service Protocol November 1998 selection bias caused by communities of interest. For example, if the San Fransisco Bay Area is a community of interest, a large percentage of calls originating from the Bay Area will also terminate there. If San Fransisco becomes a 100% IP community, then a majority of calls will be IP-IP, within-the-area calls. Only calls to PSTN communities of interest would require a gateway. This argument is also true for PSTN communities, leading to the overall conclusion that IP-IP and PSTN-PSTN calls are favored over calls requiring a gateway. The amount of network traffic caused by running the GLS at this upperbound scale can be calculated using the estimated numbers of gateways and GLSs. For this part of the example, we will assume the gateways and GLSs are arranged in a fully connected graph. This means that each gateway is required to register with and send updates to each GLS. If gateways send a 1kB packet every thirty minutes to each GLS, then each gateway is generating 10.6kb/s of traffic. Each GLS would receive a large number of updates every half-hour, equaling 530kb/s of traffic. The maximum network traffic for GLS registration and updates will be 1.3Gb/s across the global IP infrastructure. The amount of bandwidth consumed is inversely proportional to the amount of time between messages. For example, if the update interval were reduced to 1 minute instead of 30 minutes, then the total consumed bandwidth would be almost 40Gb/s. It is therefore important to set the timing variables in the protocol very carefully to prevent over consumption of network resources. Although the 1.3Gb/s of traffic might seem large by modern standards, it will likely seem negligible to the networks of fifteen years from now. Although this protocol is designed to run as a single large-scale system, it is possible that the protocol could be adapted as an internal standard run by private companies. For example, each IXC, ILEC, and PTT might run its own private GLS, and there would only be communications between administrative domains when an appropriate business relationship had been established. We can illustrate the effects of this model on network traffic caused by the protocol, by assuming that the number of GLSs and gateways stays the same as above, but that they are equally divided among the GLS providers. If there are N providers, then the traffic on each provider's network will equal the total network traffic calculated above divided by N squared. This happens because each provider runs 1/Nth of the total gateways and each gateway only need to communicate with 1/Nth of the total GLSs. If we sum the traffic for all N providers, we see that total network traffic for this model equals the traffic of the previous model divided by N. Other than bandwidth consumption, the major concern about using SLP to run GLS is that SLP was designed to run on a LAN in a single Agapi, Chiu, Chong, Phillips, Willingham INI[Page 13] Internet-Draft Gateway Location Service Protocol November 1998 administrative domain. Expanding SLP to operate in a WAN environment raises many manageability concerns. Security is probably the most profound of these concerns and thus merits its own section (Sec. 5) for an expanded discussion. Other problems focus mainly on discovery and consistency across the system, such as how does a gateway find out about GLSs to advertise to and visa versa. There is also the possibility that the state carried by different GLSs may be different at any given time. These concerns are addressed in Section 4.1, "GLS as an SLP Service." 3.2. GLS Service Load and Caching We have made the argument above that SLP can be scaled up to run in a WAN environment. In this section we discuss how caching of information can be used to reduce the load on the GLSs, making large-scale implementation more feasible. Allowing service replies from the GLSs to be cached by the endpoints will reduce the number of queries that must be preformed by the GLSs. If we tap in to the previous argument's findings, we can characterize the benefits of using caching. Using the numbers of 6.25 trillion calls per year, a busy hour factor of five, and 2400 GLSs, allows us to calculate a service rate of 415 service requests per second per GLS during busy hour calling. These service requests can be arbitrarily complex and can require a large amount of processor cycles to resolve the query. Using caching in the system will not speed queries, but it will reduce the number of service requests. If a single endpoint that is an IP phone caches all of its service replies, it is not likely to experience many benefits. The benefits will only come if the user calls a small set of numbers and calls them more frequently than the service replies expire. If the caching endpoint is a gatekeeper, the benefits of caching are more substantial. For example, a corporation that has a gatekeeper represent all of its IP phones would be able to cache information about all of the corporate gateways employed by any of its callers. So calls from headquarters to branch offices would not require sending a service request to the GLS because the request could be served out of the gatekeeper's cache. The expected reduction in service requests that must be served by the GLS can be calculated by making some assumptions about the likelihood of an acceptable service reply being in an endpoint's cache. For this argument we establish three service levels for caching; no cache, small cache, and large cache. If local carriers are running GLSs, it is likely that they will cache information about how to terminate all local calls. For this reason we have used information showing that 75% of calls are local, 10% are intralata, and the remaining 15% are interlata, international, etc. [10]. So for this Agapi, Chiu, Chong, Phillips, Willingham INI[Page 14] Internet-Draft Gateway Location Service Protocol November 1998 argument, we assume 15% of endpoints do not use caching, 10% have a small cache, and 75% use large caches, with respective cache hit probabilities of 0%, 30%, and 80%. Under these assumptions, the service rate of service requests per second per GLS during busy hour calling is reduced to around 150. Recall that this is a worst case analysis. Given any communities of interest the number of setup queries will be greatly reduced. For caching to be at all useful there must be a reasonably high probability that a record will be in cache when a call setup attempt occurs. The easiest way to increase the cache-hit probability is to increase the lifetime of a record. This allows the caching device to hold on to the record for a longer period of time. In the above analysis the assumption that 75% of users will use large caches was based on the statistic that 75% of calls are made to a local number. For this type of calling we suspect the users will use a carriers gatekeeper, and that such gatekeepers have large stable caches. This is because the gatekeeper is run by the same entity that administers many of the local gateways, and the entity can thus increase the lifetime of gateway records to increase the usefulness of its caching systems. 3.3. Thrashing Ideally, each gateway should stand an equal chance of being selected by a random user. In reality, every end-user's calling requirements differ and may in fact show a certain level of bias towards some attributes. If the number of users sharing the same preferences is substantial, this may result in a specific gateway being requested by more users than it can handle. This results in the gateway being overloaded in a very short period of time and causes it to be blocked since all ports are in use, forcing users to redirect their traffic to alternative gateways. When the gateway becomes available again, it will soon be flooded with requests, assuming that the users' profile remain unchanged at any given random time. This phenomenon is known as thrashing. Thrashing occurs if most users' basis of gateway selection is common. One possible cause of thrashing is when most users request to complete their call through the lowest-cost gateway. This will potentially route most network traffic to that gateway domain and cause an oscillation problem as described. It is possible that vendors would introduce business practices to limit thrashing. For example, long term volume agreements with clients would serve as an incentive to choose the same gateway over another. A coalition can be formed in advance to predetermine the vendor. However, this would shift the gateway location service to the Agapi, Chiu, Chong, Phillips, Willingham INI[Page 15] Internet-Draft Gateway Location Service Protocol November 1998 coalition, as they would wield much influence on which gateways will be chosen. This results in a simplified version of the GLS. A better solution would be to prescribe a specific mechanism within the GLS that minimizes the likelihood of thrashing. If the blocking probability were to be reported not as an absolute number but with courser granularity, this would result in more gateways meeting the same selection criteria. Thus, the selection of gateway would become apparent to the user. What the user perceives as identical will in fact be a random choice. This improves load balancing among the gateways. In the same fashion, an increase in the granularity of price has a dampening effect on competition between GLSs, as users will have more information to make a selection. If we require longer averaging periods for reporting blocking probability, second-to-second gateway information updating would become irrelevant. Coarser granularity for the update interval would reduce oscillation. It also increases the likelihood of cache hits. On the other hand, if there were less frequent updates, reported information would more often be out of date or stale. 4. Overview of SLP The Service Location Protocol (SLP) is simplifies the discovery and use of network resources and is suited for establishing connections between network peers that offer or consume generic services. An important feature of the SLP is the provision for the dynamic location of available resources. Service Location Protocol defines three types of agents: 1) User Agents, which acquire service handles for user applications; 2) Service Agents, which advertise service handles 3) Directory Agents, which collect together service handles in specified scopes. Applications running at a host are represented by a user agent which understands the service and resource needs of the application, and each network service is represented by a service agent which makes it available to user agents. SLP offers support for allowing network resources to be collected together into administrative domains called "scopes". Resources under a common administrative control are good candidates for inclusion in the same scope. User agents are typically configured (dynamically by DHCP, or as derived from initial computer setup) with the name of their administrative scope. Afterwards, each user agent includes its configured scope in service requests, which enables access to services configured to operate within that scope. Scopes may also indicate geographic proximity or network topology. Service Location is also designed for both interactive and non- Agapi, Chiu, Chong, Phillips, Willingham INI[Page 16] Internet-Draft Gateway Location Service Protocol November 1998 interactive use. As user agents are deployed that can manage their applications needs automatically, they can take advantage of the robust and efficient mechanism afforded by Service Location. As services are replaced or taken out of service, such User Agents will simply discover alternate or replicated servers and continue operation. On the other hand, interactive use of Service Location gives the user the most complete possible information about the services available and configured for use within their local domain. The two main functions are: - Obtaining service handles for User Agents - Maintaining the directory of advertised services The three auxiliary functions are: - Discovering available service attributes - Discovering available Directory Agents - Discovering the available types of Service Agents 4.1. Gateway Location Service as an SLP Service Terminology User Agent (UA) A process working on the user's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents. The User agents are the H.323 devices - clients (endpoints and Gatekeepers) Service Agent (SA) A process working on the behalf of one or more services to advertise the services. The Service Agents are the Gateways. Directory Agent (DA) A process which collects service advertisements. There can only be one DA process running on a given host. The Directory Agents are the Gateway Location Servers. Service Type Each type of service has a unique Service Type string. The Service Type is service:gwloc URL: A Universal Resource Locator [8]. 4.1.1. Protocol Overview The User Agent (Gatekeeper or H.323. endpoint) sends a Unicast Service Request to the Directory Agent (Gateway Location Server) specifying the E.164 number it wants to reach and optionally a predicate that specifies other criteria the Gateway(s) must satisfy. Gateway Location Servers responds by sending a Unicast Service Reply which contains the URLs of Gateways that can reach the specified number and satisfies the criteria specified in the predicate. Agapi, Chiu, Chong, Phillips, Willingham INI[Page 17] Internet-Draft Gateway Location Service Protocol November 1998 +------------+ ---unicast SrvRqst---> +-------------------------+ | Gatekeeper | | Gateway location Server | +------------+ <---Unicast SrvRply--- +-------------------------+ The URLs contain the information about the attributes specified in the predicate. SLP provides a feature that allows a User Agent to discover the location of the Gateway Location Server. This is done either by sending out a multicast Service Request with the scope specified or consulting a certificate authority that signs certificates for the GLS (see section on Security). Gateway Location Servers send back a unicast Service Reply which contains information on their location. Gateway Location Servers will frequently send out unsolicited DAAdvert multicast messages +------------+ --Multicast SrvRqst--> +-------------------------+ | Gatekeeper | | Gateway location Server | | | <--unicast DAAdvert--- | | +------------+ <--Multicast DAAdvert- +-------------------------+ SLP also provide the feature where Service Agents (Gateways) advertise themselves by sending out SAAdvert messages. This must not be done in the Gateway Location Service Protocol. Gateways send information about the services that they provide to Gateway Location Servers using the server-registration message. This is a unicast SrvReg message. The attribute- list field in the message will contain an XML document string that contains all this information. The Gateway Location Server responds by sending back a unicast SrvAck. +------------+ ---unicast SrvReg----> +-------------------------+ | Gateway | | Gateway location Server | +------------+ <---unicast SrvAck---- +-------------------------+ Gateways discover the locations of the Gateway Location Server in the same way as Gatekeepers do. +------------+ --Multicast SrvRqst--> +-------------------------+ | Gateway | | Gateway location Server | | | <--unicast DAADvert--- | | +------------+ <-Multicast DAAdvert-- +-------------------------+ List of Messages used by GWLSP Message Type Abbrev F-ID Origin Dest. Type Agapi, Chiu, Chong, Phillips, Willingham INI[Page 18] Internet-Draft Gateway Location Service Protocol November 1998 Service Request SrvRqst 1 UA GWLS Unicast Service Request SrvRqst 1 UA/GW GWLS Mulitcast Service Reply SrvRply 2 GWLS GK Unicast Service Registration SrvReg 3 GW GWLS Unicast Service Acknowledge SrvAck 5 GWLS GW Unicast DA Advertisement DAAdvert 8 GWLS GWLS/GK/UA Multicast Service Deregister SrvDeReg 4 Attribute Request AttrRqst 6 Attribute Reply AttrRply 7 Service Type Request SrvTypeRqst 9 Service Type Reply SrvTypeRply 10 SA Advertisement SAAdvert 11 SLP provides this list of messages. In SLP, SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST also support SrvReg, SAAdvert and SrvAck.. For UAs and SAs, support for other messages are OPTIONAL. List of GWINFO Tags and corresponding Attributes: +------------------------+------------------+-------------------+ | GWINFO tag | attribute | Possible Values | +------------------------+------------------+-------------------+ | | ver | | +------------------------+------------------+-------------------+ | | start | | | | end | | +------------------------+------------------+-------------------+ | | id | | +------------------------+------------------+-------------------+ | | as | | +------------------------+------------------+-------------------+ | | Point of Contact | | | | entry | H.323 Signaling | | | | Protocol | | | | SIP signaling | | | | Protocol | | | | URL format | +------------------------+------------------+-------------------+ | | payment | | +------------------------+------------------+-------------------+ | | qos | RSVP diffserv | +------------------------+------------------+-------------------+ | | crypto | DSA RSA | +------------------------+------------------+-------------------+ | | prefix | | Agapi, Chiu, Chong, Phillips, Willingham INI[Page 19] Internet-Draft Gateway Location Service Protocol November 1998 +------------------------+------------------+-------------------+ | | period | | | | endtime | | +------------------------+------------------+-------------------+ | | codec | | +------------------------+------------------+-------------------+ | | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of predicate string | Service Request \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The user Agent (the H.323 gatekeeper) issues a Service Request (SrvRqst). The structure of the SrvRqst is shown above. is the Previous Responder List String: This is the type of service required by the Gatekeeper. In our case, the service-type is GWLOC represents the service type String. The primary use of Scopes is to provide the ability to create administrative groupings of services. Scope in GWLSP will be used to defined as a GWLOC protected scope. This shall be the default scope. Therefore, for our protocol, the Service Request is considered to of DEFAULT scope. Hence our SCOPE is DEFAULT gives the Agapi, Chiu, Chong, Phillips, Willingham INI[Page 21] Internet-Draft Gateway Location Service Protocol November 1998 is a LDAPv3 search filter [14]. In our protocol, this is the field present, and where we specify our query. The values in this field are compared to each registered service. If the attribute in the filter has been registered with multiple values, the filter is compared to each value and the results are ORed together. Note the matching is case insensitive. For the predicate, the only compulsory attribute for a non-empty predicate string shall be NUMBER.

is the predicate string Examples =service:gwloc =DEFAULT

=(empty String) This is a minimal request. It matches all GWLOC services advertised =service:gwloc =DEFAULT

=(number="14122687195") This is a request for the gateways that can reach the number 14122687195. A match will be done based on the number and the longest prefix match found for this number. This returns the URLs of the gateways that can reach this number. No conditions are specified here. =service:gwloc =DEFAULT

=(&(number="14122687195") (codec = "G.711")) This request specifies the codec required to complete the call. This returns the URLs of Gateways that reach this location and support the codec G.711. =service:directory-agent =DEFAULT

=(service-type="GWLOC") This request is used by the gatekeeper to discover the all the DAs that are GWLOCs These queries will be answered by the SrvRply message. The returned information will be inserted into the URL entries as specified below. Examples of more complex queries These are examples of questions that we will like to answer. For gateway with URL sip: //128.2.1.22:2333, supporting codec G.711, What is the name of the Gateway? What AS do you belong to? What are your prices? What currency do you accept? What payment method do you accept? Agapi, Chiu, Chong, Phillips, Willingham INI[Page 22] Internet-Draft Gateway Location Service Protocol November 1998 What is your blocking probability? What is the endtime for this blocking probability? What are your QoS capabilities? For what period is this valid? However, due to the limitations of LDAPv3, questions like "What is the cheapest Gateway that can reach phone number xxx xxx xxxx supporting G.7xx?" cannot be answered easily. The concept of minimum and maximum does not exist in LDAPv3, hence they should be avoided. Queries using wild cards are supported. Eg. service:gwloc=DEFAULT

(&(number="14122687195") (codec="G.711")(blocking<"0.50")(qos="RSVP")) This is a request for a Gatekeeper that can complete a call to 14122687195, that supports G.711, has a blocking probability of less than 0.5, and that supports RSVP. 4.1.2.3. Service Reply 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvRply = 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | URL Entry count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The service reply contains one or more URL Entries that satisfy the SrvRqst and contain information that was requested in the service request message. Several URLs may be returned that satisfy the SrvRqst. URL Entries SLP reports URLs in protocol elements called URL Entries, which associate a length, a lifetime, and possibly authentication information along with the URL. The GWLSP uses URL Entries in two ways. One is in the Service Reply message. When used here, we call the URL entry the URL entry with Extended URL(s), since the URL portion contains other information as well as the URL. The other use is in Service Registration Messages, where the URL portion contains just the URL. The URL syntax, as shown below can be used in both cases. However we must not forget that these are two different entities - URL entries for Service Registration Messages, and URL Agapi, Chiu, Chong, Phillips, Willingham INI[Page 23] Internet-Draft Gateway Location Service Protocol November 1998 Entries with Extended URLs for Service Reply Messages. For the Service Reply message, the reported URL entries MUST contain information about the attributes specified in the predicate of the corresponding service request. Also, the Service Reply messages must always contain the 'as no' along side the URL, whether or not it was included in the Service Request predicate. The valid start end attributes in the GWINFO will be used to calculate the value for the Lifetime field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Lifetime | URL Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |URL len, contd.| URL(var length incld attrib. values in SrvReq)\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# of URL auths | Auth. blocks (if any) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Examples A response to the predicate in the Service Request Message above service:gwloc=DEFAULT

(&(number="14122687195") (codec="G.711")(blocking<"0.50")(qos="RSVP")) could be http://gwl.cmu.edu:1212/?prefix="1412268"&lm="yes"& as="345"&codec="G.711 G.723 G.729"& blocking=".10"&qos="RSVP diffserv" 4.1.2.4. Service Registration Gateways register with the Gateway Location Servers with messages that contain the attributes of the service they provide. The is the same service type specified in the Service Request Message. In our case, the service-type is GWLOC The is the same as specified in the Service Request Message. We assign DEFAULT to This will contain the XML document string that contains all the information about the particular gateway. The format of XML Agapi, Chiu, Chong, Phillips, Willingham INI[Page 24] Internet-Draft Gateway Location Service Protocol November 1998 document string, and examples are given in section 4.XXX A detailed description of the attributes is given in Section 4.YYYY. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvReg = 3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of service type string | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of attr-list string | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# of AttrAuths |(if present) Attribute Authentication Blocks...\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2.5. Service Acknowledgment The Gateway Location Server (Directory Agent) returns a unicast Service Acknowledgment message to the Gateway (Service Agent) on receipt of a Service Request. It contains a 2-byte error code 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvAck = 4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2.6. Service Update We define our own message, Service update. It is identical to the Service Registration Message in all respects except one. The REFRESH flag in the header format is NOT set. This is termed incremental service registration in SLP (see section 9.3. Incremental Service Registration). The rule for incremental service registration We believe signed updates are appropriate to reduce traffic, hence the rule should be relaxed. We should allow incremental updates for GWLS with restricted scope. This is discussed further in the section on security. 4.1.2.7. Directory Agent Advertisement Agapi, Chiu, Chong, Phillips, Willingham INI[Page 25] Internet-Draft Gateway Location Service Protocol November 1998 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = DAAdvert = 8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | DA Stateless Boot Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DA Stateless Boot Time,, contd.| Length of URL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # Auth Blocks | Authentication block (if any) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2.8. Zone Transfers When a new Gateway Location Server comes online, it can request a full transfer of information from another Gateway Location Server. The New GWLS discovers existing GWLS's by listening for multicast DAAdverts that they send out. The new GWLS responds to the first DAAdvert it hears by sending out a unicast zone transfer message to that GWLS. The old GWLS then transfers all the information it has to the new GWLS. The new GWLS then sends out unicast DAAdverts to the Gateways that it now has information on, so that they can in turn send out Srv Reg messages to it to update its information. We therefore have to define two new message types that will be used for the zone transfer requests and the actual zone transfers. 4.2. Modified SLP Messages As stated above, when applying SLP to provide gateway location service, DA receives packets containing gateway information from SA and sends packets containing contact information to UA upon queries. To use SLP for the gateway location service, we need to modify or clarify some SLP message formats. In this section we discuss the following SLP message formats to tailor SLP to suit the gateway location service: Message Type Abbreviation Function-ID -------------------- ------------ ----------- Service Reply SrvRply 2 Service Registration SrvReg 3 Agapi, Chiu, Chong, Phillips, Willingham INI[Page 26] Internet-Draft Gateway Location Service Protocol November 1998 Service Update SrvReg 3 Note that the Service Update message has the same format with Service Registration. All SLP messages begin with same header format, Service Update is achieved by NOT setting the FRESH flag in header. This is called incremental service registration in SLP. 4.2.1. Using XML for Service Registration The Extensible Markup Language [13] is a meta-language that allow us to design our own markup language. Information will be more accessible and reusable, because the more flexible markup of XML. XML document is more readable than flat attributes list and is clearer to show relations among attributes by defining tag elements. There might be an interoperability concern also. A H.323 gatekeeper is likely to provide UA or SA service along with the Call Processing Language [14] service, which provides some sort of scripts to customize signaling operations. The IPTEL working group is also proposing to use XML to define a language for CPL. The interaction between gateway location and CPL services deserve further discussion. We propose to use VALID XML here. A Document Type Definition is required for valid XML documents. Service registration and update should use the same DTD definition in order to support incremental service registration easily. The DTD for gateway location service is listed below. The detailed description of gateway-specific attributes is explained in the next section, 4.2.2. ]> When SA is composing a SrvReg message, the field is replaced by the XML gateway document string. Here is a sample XML document for service registration: Agapi, Chiu, Chong, Phillips, Willingham INI[Page 27] Internet-Draft Gateway Location Service Protocol November 1998 For SrvReg incremental update messages, the format is basically the same but it could includes only required and updated attributes: 4.2.2. Attributes Descriptions The version number of the DTD of gateway information. This is a required attribute. A valid XML document contains DTD definition before document contents. Since the DTD of gateway information should be well known, we use this tag to identify the DTD version used by SA and DA. By this way we can reduce data packet size and provide the capability for future function changes. If SA sends a DTD version Agapi, Chiu, Chong, Phillips, Willingham INI[Page 28] Internet-Draft Gateway Location Service Protocol November 1998 that is not supported by DA, DA will return an error code to SA. Service update must follow the same DTD version used by the gateway registration. Re-registration is required to change DTD versions. ver String of version number. Validation of the gateway information. This tells SA when this information will be valid and expired. start ISO 8601 date/time format. The starting time when this information become effective. end ISO 8601 date/time format. The expiration time. Identifier of the gateway. This is a required attribute for either gateway information registration or update. This should exactly the same id as the gateway's authentication-verification id. This id tells the name of the gateway service provider, and also be used for checking identity during authentication phase. id X.509 Distinguished Name Autonomous System number of the gateway domain. as AS Number. Point of Contact. The transport address or URL of the contact point. Based on different signal protocols supported, the returning address could be different. The choice of different signaling protocols supported by the gateway is made available by analyzing those tags of point of contacts. Explicit IP listing is preferred since user can avoid querying DNS for IP resolution, hence shorten the entire call setup time. H.323 signaling protocol SIP signaling protocol URL format entry The corresponding URL or transport address string. For example: h323 entry="128.2.1.2:1234" sip entry="128.2.1.22:2333" Agapi, Chiu, Chong, Phillips, Willingham INI[Page 29] Internet-Draft Gateway Location Service Protocol November 1998 url entry="http://gwc.cmu.edu" url entry="iptel://gwc.cmu.edu:4321" Payment Method. There are many possible payment methods can be used here. Users may have a default billing account as usually they have for their PSTN services. Credit card and e-cash might also be used. In the latter way, we can even be able to tell whom we are going to pay for, by the billing company's merchant number. Since there are different possibilities here, we do not have a specific syntax for now. But this attribute must exist in the protocol. payment Left for further study Quality of Services capabilities supported. qos String of QoS protocols, separated by space. For example, qos="RSVP diffserv" Security protocols supported by the gateway. crypto String of cryptographic standards, separated by space. For example, crypto="RSA DSA" Prefix of E.164 numbers that the gateway provides services. DA will use maximum prefix-matching to search the gateway information database, so this is definitely a key in DA's database. prefix String of consecutive numbers Blocking Probability. The probability that not all trunks of the GW are occupied during a period of time. The averaging period is the time in minutes that the GW used for calculating blocking probabilities, and the latest end time is also noted. Clients are allowed to get blocking probability results that produced within a certain amount of time. For example, prefix blocking period endtime ------ -------- ------ ------------------------ 1412 .1 60 1998-10-05T20:00:00-5:00 1 .05 120 1998-10-04T08:00:00-5:00 blocking Agapi, Chiu, Chong, Phillips, Willingham INI[Page 30] Internet-Draft Gateway Location Service Protocol November 1998 2-digit number representing percentage period 4-digit number in unit of minutes. Averaging period. endtime ISO 8601 date/time format. The end time of the averaging period. Codec Support. This attribute indicates what kinds of codecs are supported by some prefix of a gateway. Note that it is associated with prefixs instead of an entire gateway. A gateway controller domain can have many physically independent gateways, each in charge of some prefixs respectively. codec String of codecs, separated by space. For example, suppot="G.711 G.723" Price. Here is the pricing model used by PSTN telephony. The cost for setting up a call via an ITG is e + ceiling(t / u) * p, where e is the excess charge (call originating chagre) for one call, u is the charging unit of time (in seconds), and variable t is the total time (also in seconds) for the duration of the call. Then p is the cost per timing unit. The ISO currency code is also a parameter here. prefix excess(e) unit(p) timing(u) currency ------ --------- ------- --------- -------- 1412 .1 0 0 USD 1 .25 .25 60 USD 1 .25 .025 6 USD The second and third prefix-1 examples illustrate different representations of same pricing basis. Note that users should prefer the later one since they pay less from smaller (more accurate) timing units. Another characteristic of the price attribute is the pricing schedule. Prices may be different from business hours, economy/night hours, weekend discounts, competitions... etc. This requirement is incorporated into the tag in our XML gwinfo format, which indicates the validation of gateway information (starting/ending time). The date/time format conforms to the ISO 8601 standard. Clients, or user agents, are not necessary to know contents in different validation time windows. Instead, they may get an expiration time for the current validation. excess 3-digit number representing 1/1000 of currency unit. Setup charge per Agapi, Chiu, Chong, Phillips, Willingham INI[Page 31] Internet-Draft Gateway Location Service Protocol November 1998 call. unit 3-digit number in 1/1000 of currency unit. The charging price per timing unit. timing 2-digit number in seconds. Timing unit. currency ISO 3-characters currency code 4.2.3. Extended URL for Service Reply The way DA accessing gateway information in databases depends on its own database implementation. DA is responsible to retrieve and search its gateway database properly, based on UA's query criteria. Here we discuss the required modifications on service request and service reply messages for use by UA and DA interactions. The detailed message formats and fields are introduced on section 4.1. For the service request message, first we need to define an abstract service type "gwloc" for the required field in SrvRqst. Then all URLs have the format "service::". For example, service:gwloc:h323://128.2.1.2:1234 service:gwloc:sip://128.2.1.22:2333 service:gwloc:http://gwc.cmu.edu service:gwloc:iptel://gwc.cmu.edu:4321 SrvRqst also defines a list, which is a LDAPv3 search filter. This allows UA to specify different searching attribute parameters together in a single query. A required attribute parameter is the phone number of the callee. Note that is used to match prefixes by DA, and is a new attribute parameter for the predicate list only. Other attribute parameters are as defined in the service registration section. Depending on different possible business models used, an UA may prefer the DA to return one best matched result or a list of URLs meeting its searching criteria. However LDAP filter does not provide maximum/minimum operator to constrain the searching criteria. This will prevent UA from getting single best result. To deal with this limitation, we can either prohibit the UA from submitting max/min queries or add a max/min operator into LDAP predicates. Note that searching for extreme values will require the DA to do CPU-intensive sorting which decreases system performance significantly. On the other hand, there is also an XML Query Language specification (work just started) that might be able to allow us to replace the LDAP predicate list in the future. We would assume both Agapi, Chiu, Chong, Phillips, Willingham INI[Page 32] Internet-Draft Gateway Location Service Protocol November 1998 single and multiple results can be returned and leave further issues open here. The SrvRply message contains a list of variable-length URL entries, which associate a length, a lifetime, and possibly authentication information with the URL. In order to give the UA more information for it to use in selecting from among multiple service replies, we need to associate extra attribute parameters to each URL, in the following format: srvtype://addrspec?attrparam="value"& attrparam="value"&attrparam="value"... Attribute parameters would be returned only for those attributes which appear in the UA's service request predicate list. The UA can further process the results using these attribute values. There are two required attribute parameters for the extended URL. returns the matched prefix where this entry is found, and a new , longest match, indicates if this prefix is already the longest prefix in the DA database or not. This would be very useful for caching purpose, UA can avoid querying DA again and again if it knows there is no better prefix matching possible for new queries from end users. 5. Security Considerations It is not the object of this paper to describe a security protocol that could be used with the GLP. However, the importance of this subject cannot be overlooked and we would like to comment on some of the issues. Since the security of transmission is considered within the H.323 protocol, the focus on security in the GLP falls on authentication, trust, and their application in a real-time environment. Is there a need for authentication? Who needs to participate in authentication to verify that the participating entities are who they say they are? Just imagine a GW or DA impersonator, trying to route all calls through him to reap great benefits. Definitely, the UA needs to know that it is talking to a known DA. When initiating a call, the users do not need to authenticate themselves when contacting a DA, but the DA has to. The UA should be able to verify a certificate of a DA but it is not necessary to have its own public/private key or certificate. A private key and SLP [4] can be used, but this mechanism will add computational burden and it would not scale. Since it would be computationally expensive for the DA to sign every service reply, one solution would be to use a scheme based on secret sharing. Agapi, Chiu, Chong, Phillips, Willingham INI[Page 33] Internet-Draft Gateway Location Service Protocol November 1998 While the communication between the GW and the DA can be done using ESP, it is not possible to do so over the UA - DA communication because the UA does not need to have a certificate. One mechanism that would solve the problem of proposing the secret could be the use of a secure TCP/TLS channel. The UA proposes a secret by sending it to the DA. The DA then replies with a signed message accepting the secret. The DA needs a certificate from a Certified Authority (e.g. VeriSign). The Certified Authority will distribute certificates to all DAs and GWs. It is important to realize that during a call setup, only one authentication takes place: only the DA needs to be authenticated by the UA: there will be a one way identification of the DA to the UA. In the initial registration with the GLS, the GW needs to register using public/private key. There is a cryptographic burden associated with the signature using a private key. A solution would be to use a lighter weight signature scheme that relies on secret sharing, using SLP. Having the registration completed, a shared secret is established. Furthermore, the initial registration includes a key generation number and a key as attributes defined in XML. The shared secret generated by the GW is authenticated by private key signature authentication block on registration. The secret is protected during the transmission using ESP. When sending advertisements, the GW has to be authenticated by the DA. All updates transmitted from the GW to the GLS should be signed using keyed HMAC, which will increase performance, because HMAC is fast, lightweight having keyed hashing. The GW should be authenticated asynchronously, at the time of the advertisements and not during call setup. This provision will cut in the call setup time. Simply knowing who an entity is does not mean that that entity can be trusted. The issue of trust is closely related to the business model in which the entities of the GLP operate. Since interconnection is mandatory as specified by the Telecommunications Act of 1996, almost any entity (ISP, LEC, IXC, etc.) can operate a GW or a DA. In this environment, even if authentication is valid, the question remains whether to trust an entity or not. Consider for example the case where a UA authenticates successfully the DA belonging to, say AOL. Should the UA trust the entity to route the call to the best of its knowledge? Is there a threat that AOL will try to benefit by directing calls to some preferred GW? Consider another example in which a Gateway of the company XYZ advertises a very good price. In this free market environment, should a UA trust company XYZ? What if a GLS is not in a UA's administrative domain? Should the UA trust the GLS and give out the user's preferences compromising the privacy of the user? The answer to the trust problem lies in the way of how trust is Agapi, Chiu, Chong, Phillips, Willingham INI[Page 34] Internet-Draft Gateway Location Service Protocol November 1998 established currently in the IP or PSTN domain. In the IP domain, the systems which can generate digital signatures are those which have been configured by administrators in advance. The agents who verify signatures may assume the data is trustworthy since administrators have ensured the cryptographic keying of SAs, UAs or DAs reflect trustworthiness. For the PSTN, in the U.S. Common Carriers (CC) need to be certified by the FCC or state regulatory commission, in order to establish a minimal trust. This established trust carries on as CCs interconnect with other carriers and business relationships are formed. If complaints surface about the operations of that CC, its license can be revoked. By the same token, any new entity willing to operate a GW or a DA, will have to register with the FCC or an already registered entity (LEC, IXC, etc.). Once the registration is completed, the new entity can be trusted until there is reasonable proof not to do so. Security protocols like SSL (Secure Socket Layer, is based on RSA Data Security's approach and which is used by both Netscape Navigator and Microsoft Internet Explorer to authenticate and encrypt transmissions over the Internet), digital signatures (used to secure documents, making them unalterable except by the original sender), and public key protocols (allow the sender to scramble the data using the public code advertised by the intended receiver, but only the receiver can decipher the data using a private code) work fine when data does not require real time transmission. However, with IP telephony the communication has to be real time and the computation for encryption and decryption of packets needs to be optimized to decrease latency. The use of SSL will have too much overhead over TCP: 7 packets to establish connection. One solution would be to use SSL to issue a session key with serial number. A request for a serial number can be resolved through a cache lookup: is the serial number in the cache? If it is, then use the session key, otherwise generate a new key. 6. Conclusion To solve the gateway location problem, we try to do careful identification on its requirements and features that span from application layer to routing layer in the Internet. This document incorporates ideas from several related protocols and standards, while some issues are still unsolved here and hence need further study. Most of the unsolved ones are related to uncertainty on business models. The gateway location service protocol is capable to support not only existing PTSN business models, but also new ones that can be derived from the protocol itself. We will continue to Agapi, Chiu, Chong, Phillips, Willingham INI[Page 35] Internet-Draft Gateway Location Service Protocol November 1998 improve what we have done here and hope that our work could have some contributions to the Internet Telephony society. 7. Abbreviations AS Autonomous System (BGP) BGP Border Gateway Protocol BMA Brokered Multicast Advertisement BSD Block Structure Descriptor CC Common Carrier DA Directory Agent DHCP Dynamic Host Configuration Protocol ESP Encapsulating Security Payload FCC Federal Communications Commission GK H.323 Gatekeeper GW Gateway GWC Gateway Controller GLP Gateway Location Protocol GLS Gateway Location Server GLSP Gateway Location Service Protocol HMAC Hashed Message Authentication Codes IP Internet Protocol ISP Internet Service Provider ITG Internet Telephony Gateway ITSP Internet Telephony Service Provider IXC Interexchange Carrier LEC Local Exchange Carrier LS Location Server PSTN Public Switched Telephone Network SA Service Agent SLP Service Location Protocol SPI Secure Parameter Index SSL Secure Sockets Layer TLS Transport Level Security UA User Agent URL Universal Resource Locator XML Extensible Markup Language 8. Acknowledgments We would like to thank Jonathan Rosenberg and Henning Schulzrinne, the authors of Brokered Multicast Advertisement, for the work that they have done in defining the gateway location problem [5]. The authors take responsibility for any error or omission in the interpretation of their work. This work reflects the views of the authors and should not be interpreted as representing the views of Agapi, Chiu, Chong, Phillips, Willingham INI[Page 36] Internet-Draft Gateway Location Service Protocol November 1998 Carnegie Mellon University. We would especially like to thank Professor Marvin Sirbu, our advisor, for his valuable thoughts, insights, and guidance on various aspects of our research. 9. References [1] H. Olivier, H. Christian, L. C. Herve, "GSTN/TIPHON interworking using a country code", ETSI TIPHON, November 1997. [2] R. Faltstrom, B. Larsson, "Where to terminate a phone call", draft-faltstrom-e164-00, June 1998. (work in progress). [3] J. Rosenberg, H. Schulzrinne, "A Framework for a Gateway Location Protocol", draft-ietf-iptel-gwloc-framework-00.txt, July 1998. (work in progress) [4] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service Location Protocol, Version 2. draft-ietf-srvloc-protocol-v2-09.txt, October 1998. (work in progress). [5] J. Rosenberg, H. Schulzrinne, "Internet Telephony Gateway Location", IEEE, 1998. [6] International Telecommunication Union, Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service, Recommendation H.323, Telecommunications Standardization Sector of ITU, Geneva, Switzerland, May 1996. [7] A. Brown, "E.164 Resolution Solution Proposal", August 1998. [8] D. Skran, "Framework for the Proposed Gateway Device Control Protocol V4.2", ITU, September 1998. [9] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [10] "Trends in Telephone Service," Federal Communications Commission, July 1998. [11] T. Bernes-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators (URL). RFC 1738, December 1994. [12] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [13] W3C Recommendation, "Extensible Markup Language (XML) 1.0", February 1998. Agapi, Chiu, Chong, Phillips, Willingham INI[Page 37] Internet-Draft Gateway Location Service Protocol November 1998 [14] J. Lennox, H. Schulzrinne, "Call Processing Language Requirements", draft-ietf-iptel-cpl-requirements-00.txt, July 1998. (work in progress) [15] J. Rosenberg, H. Schulzrinne, "A Framework for a Gateway Location Protocol", draft-ietf-iptel-gwloc-framework-01.txt, October 1998. (work in progress) Authors's Addresses Ciprian Agapi Email: ciprian@andrew.cmu.edu Chien-Hsiu Chiu Email: chiu2@andrew.cmu.edu Thoong-Shin Chong Email: tchong@andrew.cmu.edu Harold Phillips Email: haroldp@andrew.cmu.edu Brian Willingham Email: bdw2@andrew.cmu.edu Information Networking Institute Carnegie Mellon University A020 Hamburg Hall 5000 Forbes Avenue Pittsburgh, PA 15213 Phone: 412-268-7195 FAX: 412-268-7196 Agapi, Chiu, Chong, Phillips, Willingham INI[Page 38]