Minutes of the iptel wg session at the 42nd IETF, Chicago, IL 8/24/98 Notes By: Francois Menard, Wilhelm Wimmreuter Reported By: Jonathan Rosenberg The session opened with a presentation of the agenda, which was basically three main items: 1. Open issues in gwloc framework document 2. Call processing syntax update 3. Fixing charter and milestones update There was no objection to the agenda, so the meeting progressed to a discussion of the gwloc framework open issues. The first item was to try and define some common terms so as to establish a consistent framework for discussion. Several terms were defined, including gateway, user agent, location server, and provider. The question was raised about the relationship between a gateway provider, ISP, ITSP, etc. The chair indicated that in our architecture, a provider provides gateways, and that this provider need not be an IP service provider. As a result, a provider "domain" in our context is not the same as an ISP domain or Autonomous System (AS) in routing terminology. The domain represents the logical collection of gateways and location servers owned by a single entity. The next issue for discussion was the scope of the gateway discovery being worked on. The chair noted that it was important to decide which case we are working on, since the requirements for each are different, and therefore the protocol might be different in each case. It was noted that even though we engineer the protocol to solve one of the cases, if it happens to be a good fit for one of the other ones, great, but we shouldn't engineer for it. Four cases were presented: 1. Intra domain. In this case, the gateways are all owned by the same administrator. The gateway location protocol allows a number of location servers, also owned by this provider, to automatically learn about the gateways within the domain. In this case, issues such as policy and aggregation, and requirements for security, scalability, and robustness, are different than in the other cases. 2. Inter-domain (1): In this case, the gateway location protocol is being used to exchange information on gateways between providers. Providers have location servers, which know about gateways within their own domains. How they know is the scope of an intra-domain gateway location protocol (which is something different). This information is exchanged with peers, and may be aggregated and further passed on to other peers. The "peering relationships" between provider location servers are not the same as the BGP peering relationships used to exchange routing. The protocol is independent of normal routing exchanges. In order to exchange information, a pre-established peering relationship must be built ahead of time between providers. 3. Inter-domain (2): In this case, the gateway location protocol is also used to exchange information between providers. However, it would be based on some kind of multicast model, so that a gateway provider would just advertise widely its gateway characteristics. Any location server or client could receive these advertisements and learn about remote gateways and gateway attributes in remote domains. This differs from inter-domain (1) in that no pre-established relationships need to exist. It becomes an "open market" allowing anyone to advertise and anyone to receive. 4. Inter-domain (3): This case is like (1), except that the gateway reachability information and attributes are pushed into existing inter-domain routing protocols. This has been suggested on the list. The chair raised concerns about this overloading existing routing infrastructures, and also requiring significant upgrades for carriers, even those who don't offer IP telephony gateway service. There was consensus that we shouldn't be doing this, although it had been pointed out that the E.164 space would fit into IPv6, so it might be appropriate to do this in that context. Then he proceeded by explaining the importance of defining in the draft how to deal with inter-domain vs intra-domain, since they have different requirements. There was then some discussion on these various scenarios. An important question was raised about the distinction between discovery and qualification. Since the domains we are talking about are virtual, a provider may learn about another gateway, but the gateway may not actually be reachable by the provider, or the gateway may be reachable but by unacceptable QoS. The chair commented that he felt it was not within our scope or charter to add QoS routing into the protocol. He proposed to leave path qualification" to external means, and not part of the protocol. It was argued that it needs to be integrated into the protocol. There was no consensus and it was decided to try and resolve it offline. It was then suggested that a query could be made every time a gateway was required, and the gateways could return some kind of bid, allowing the caller to decide among the bids and choose a gateway. The chair raised concerns about the scalability of a multicast query for each call setup, and he argued that routing protocols propagate this information ahead of time to eliminate these kinds of queries. There was general consensus that we were trying to solve the inter-domain (1) problem. The chair then went on to further scope the inter-domain (1) problem. The first question was whether we were trying to solve the single hop or multiple hop problem. In the single hop case, providers exchange information about their own gateways with each other. In the multi-hop case, there are intermediate providers which can aggregate and advertise this aggregate information. In either case, the call terminates on a single gateway, but the issue is really whether there are intermediate location servers (which would often be gatekeepers or SIP servers) or not. The chair indicated that the difficulty with the multi-hop case is that its not clear aggregation is possible, since there are so many attributes. Scott Petrack than pointed out that in order to make this determination, we should consider what attributes might actually be used for a gateway. Scott Bradner indicated, however, that even in the simple one hop case, a providers location server will need to aggregate gateway information from its own gateways. As a result, we are effectively doing the multi-hop case anyway. The chair agreed, and consensus was reached that the multi-hop, single gateway case would be supported by the protocol. It was agreed, however, that aggregation was a complex problem. The next issue was that of multiple gateways. In this scenario, for example, a call begins from a PC endpoint, hops through several location servers, jumps off the IP network onto the PSTN through a gateway, to another gateway, back onto the IP network, through some more location servers, and then back off the IP network to the PSTN towards a PSTN terminal. This has been mentioned on the list as something we may want to do. The question is - does it require additional support from the protocol, and if so, do we want to engineer that support into the protocol? Jim Udall felt that such a scenario might arise in the connection of islands of mso's. The chair pointed out, however, that instead of treating the PSTN as the PSTN, and terminating the application layer protocols on the gateway, one could treat the PSTN connection as a dial on demand IP link, and thus the problem still effectively looks like a single gateway case. Scott Bradner also pointed out that one could always use these intermediate hop-off and hop-back-on connections internally without advertising them, so that the protocol doesn't need to be aware that its being done. There was general consensus that we should not try and solve the multiple gateway problem. The next issue was what the attributes for a gateway might be. The chair presented a slide with a number of posible attributes, which include phone number reachability, cost, protocol support, encryption, call features, codecs, administrator, vendor, capacity, etc. It was pointed out that many of these were static, and that we would need to handle dynamic attributes too. Christian Huitema expressed concern that too many attributes will cause a "multiplication effect" in the aggregated announcements from providers. Therefore, to be scalable, we must stick to attributes which are hop by hop or which can be aggregated end to end. It was mentioned that a MIB is being developed for gateways, and that this would be a valuable starting point for determining which attributes might be propagated. There was no consensus on which attributes might be included, and it was agreed to continue discussions offline and on the list. The next issue was what range of numbers a gateway can be allowed to advertise reachability to. In other words, gateways can complete calls to certain sets of telephone numbers, and these need to be advertised. Is there a restriction on what this set is? The chair indicated that there are reasons why a provider would want to advertise only local numbers (thats what will be cheapest), or all numbers (a gateway can complete a call to any number - its in a providers business interest to advertise as broady as possible). The chair indicated that the decision is really a business one, and that he felt the protocol should be engineered to support whatever business decision a provider makes. Scott Bradner agreed, and the consensus was to engineer the protocol to support whatever phone number range a provider decides to advertise. It was also pointed out that there was an ion protocol for phone number advertisements in an IP to ATM address resolution service, and that we should take a look at this to see if its relevant and how they handled some of these problems. The next open issue discussed was that of how a user specifies input to the selection process. The chair presented a model which consists of a front end and a back end. The back end is the protocol which distributes gateway attributes among service providers. Based on the information received, service providers can aggregate, filter, and propagate this information, and also build up their own local databases of gateways. When a user wants to make a call, it seems there are many ways in which they can access this database and express preferences. These include: 1. An LDAP or other database query from the client to the location server 2. The Service Location Protocol (SLP) - a location server can act as a DA, and the clients can run UA's and formulate service queries 3. The location server can create dynamic web pages, and the clients can browse the web pages, 4. The location servers also act as gatekeepers. When the client sends a call setup message to the gatekeeper, the gatekeeper consults its gateway database and forwards the request accordingly 5. The location servers act as SIP servers. A SIP INVITE request from a client can contain preferences about gateway selection. It doesn't seem to be mandatory to standardize a single mechanism. Different providers can use different approaches as they see fit. Thus, the chair proposed that the group work just on the back end mechanism, and leave the front end mechanisms for later on. Masataka Ohta asked for the front end mechanisms to be added to the charter right away. Scott Bradner indicated that first we should at least complete the gateway location framework document, and then we could consider adding items to the charter. The next item on the agenda was updating of the milestones. The chair indicated that the milestones were outdated, for two main reasons: (1) the group changed the order of doing things, so that we are focusing on the gwloc protocol first, and (2) the timelines were proposed well before the wg was approved, so they were already out of date by the time the group began meeting. An additional problem was that a gwloc framework document was not part of the current charter. It was proposed that it be added. The following dates were proposed as main milestones: 1. gwloc framework document submitted to IESG: Jan 99 2. gwloc protocol document submitted to IESG: Apr 99 3. call processing syntax framework submitted to IESG: Apr 99 4. call processing syntax submitted to IESG: Sep 99 The area directors agreed that these dates were acceptable, and consensus was achieved that we would go with these. The next item on the agenda was a presentation by Jonathan Lennox on the call processing syntax. He indicated that the plan for the scripts is to live anywhere (end systems or network servers), be persistent for a transaction, and be independent of the means by which they are transported. The last meeting had brought some questions regarding feature interaction issues. Jonathan addressed the interaction issues from three definitions. In interaction case 1, two features are on at once - for example "call waiting" and "call forward busy". In the CPL context, services are not defined by names, but rather on conditions, so this kind of interaction shouldn't be a problem. Interaction case 2 is when multiple scripts execute on the same server. In general, there will be some ordering to these, and so they will execute in series as if they were actually running on separate machines. This leads to the third case, that of multiple scripts on different servers. Some interactions are signaling protocol issues (for example, the signaling protocol should probably detect loops to avoid the problem when call forwarding is executing on both machines), and some are unavoidable (outgoing call screening on one machine, and transfer on another machine, where the transfer is to a forbidden site). Jonathan then presented an idea to use XML as a syntax for creating the call processing script. The main motivation is that it is safe, easily written by hand or computer, and easily parseable. Furthermore, since it is good at representing tree like structures, it can easily represent services which are defined by tree like decision, as is often the case in IN. There are many open issues remaining, some of which were presented. For instance, how are timeouts handled? What is the granularity of features specified in the syntax? Should call queue, for example, be a primitive or constructed from lower level primitives? Should the syntax be call specific, or apply to other communications services, such as fax, email, and presence? As time was running out, there was little time for discussion or questions. There were a few comments on related work. With that, the meeting was adjourned.