iptel Meeting Minutes 44th IETF Minneapolis, MN Tuesday, Mar 16 1300-1515 Minutes prepared by: Jonathan Rosenberg Minutes taken by: Joerg Ott The iptel working group met for a single, busy, two hour session. There were neraly 200 people in attendance. The session was multicast on the mbone. The meeting started with agenda bashing. The original agenda was reordered. Squire disussed the open attribute issues first, and then he discussed the SCSP approach for GLP. Following that, Hussein Salama presented the TBGP approach for GLP. Jonathan Lennox then discussed CPL transport issues, followed by the CPL itself. GLP Data Representation Issues ------------------------------ Matt Squire, Nortel Networks Slides at http://www.bell-labs.com/mailing-lists/iptel/glp_data.ppt [Slide 2] There are a number of things required for the GLP routing objects. The phone number prefix is the most important one, and then there are a number of attributes that describe the route to this prefix. Some of these are optional, and some should be mandatory. [Slide 3] One of the main issues is how to represent phone numbers. There has been much discussion of this on the list. The encoding must be determined, along with the set that can be represented (range, prefix, regular expression), and whether we need "black holes". For the encoding, the proposal was to use a hex (i.e., 4 bits) representation for each digit, as this was more compact than the other proposals (char = 8 bits per number, or BCD of 8 bits per number). The general sense that encoding determination was premature, since there hadn't been sufficient discussion on the list in this in particular. Furthermore, the encoding should depend on how we do aggregation and what the numbers represent. Then, the tough issue of number representation (ranges, prefixes, or regexp) was presented. It was first argued that ranges were not much more useful than prefixes. However, Scott Petrack raised an interesting requirement. A certain ISP owns every 123-4567 number in each area code in the US, used as their "universal dialup number". A gateway might like to service a number like this, but it can't be represented with either ranges or prefixes. Regular expressions could work. However, David Oran raised the important point that the definition of "longest prefix match" is ill defined in the case of regular expressions. Some notion of this concept would be needed in order to enable routing to properly occur. The discussion then moved to the issue of "black holes"; the problem being that a set of prefixes might not be aggregatable since one of the numbers needed to perform the aggregation simply doesn't exist. This prefix is essentially a "black hole" in the numbering space. The question is - do we worry about this, and if so, what to do? The issue is related to whether aggregation is performed semantically (the LS knows the structuring of numbering plans, and groups together numbers which are groupable, by region, for example) or syntactically (based purely on redundancy in the bits, like is done with IP addresses). The question of what does it mean to "not exist" was raised. Are these numbers which will never exist, or temporarily out of service? What happens if an LS advertises a route to an aggregate since it thinks one of the routes that was aggregated doesn't exist anyway, but it actually does? Another issue is whether these black holes might explicitly be communicated as part of the route itself. It wasn't clear that this was useful. It was mentioned that the representation should support syntactic aggregation, but that semantic aggregation was allowed. An LS could advertise any prefix so long as it was sure it could reach that prefix, however this determination is made. Effectively, advertising a prefix was a "promise" of the ability to deliver service to this prefix. There was no consensus on any of these issues. It was agreed more discussion is needed on the list. [Slide 4] The next issue was what kind of numbers are allowed in GLP. Consensus was reached on the list that routable PSTN numbers are certainly included. There was apparent consensus that private numbers were not permitted (GLP being an inter-domain protocol). The open issue was with numbers like 800 numbers, or numbers which did not have global uniqueness (800 numbers are like this, how they are routed depends on where the call comes from). It was proposed [slide 5] that the LS need not understand the properties of these various numbers, and that any properties be conveyed by attributes. Matts' slides discussed the various ways in which a particular number might be treated based on caller locale, private numbering plans, time of day, and so on [slides 6,7,8,9]. After some discussion, there seemed to be consensus that for numbers which were not globally unique, we add an attribute (perhaps not called scope, a term over-abused on the list) which effectively makes the number unique. This attribute is, in fact, considered as nothing but an extension of the number itself, so the same aggregation rules for numbers apply to it. As for time of day sensitivity, there seemed to be consensus to keep these things out of GLP. It was recognized that there was a need for a "translation service", which would take a number like an 800 number, and based on any number of parameters provided by a user, result in a translation to a routable PSTN number. Then, GLP could be used to find the gateway towards this routing number. This translation service seemed to be within the scope of the enum group, under formation. The next issue discussed was that of lifetime [Slide 10]. Gateway objects may have finite lifetimes. For example, an 800 number may only be valid for a certain amount of time. So, do we include the lifetime in the routing object as an attribute, or should the advertising LS simply withdraw the route when it expires. There was general consensus that the route should be explicitly withdrawn, and there would be no lifetime attribute. This is consistent with existing routing protocols. An interesting and related issue was brought up. In GLP, an LS need not change the next hop for a route it propagates. So, in the following case: GW1 -----> LSA ------> LSB LSA knows of GW1, and sends an advertisement for it to LSB. The next hop is listed as "GW1" in the advertisement to LSB. Now, if the peer relationship between LSA and LSB is lost, should LSB assume the route to GW1 is also lost? Since LSA is not a next hop for signaling, its status as up or down has no bearing on whether the call can be completed or not. There was no consensus on this issue. The next issue was signaling protocols. These are an attribute of a gateway [slide 11]. The question was which protocols? There was consensus that H.323 and SIP were yes. Since MGCP is a control protocol, and not a signaling protocol, MGCP seemed unneeded, along with SGCP and IPDC, its predecessors. With H.323, the question was whether RAS and Q.931 were separate or not. There was no decision. It was agreed that we would provide a few tags, and define IANA procedures for registering new ones for future signaling protocols. The final attribute issue discussed was capacity [slide 12]. The questions are absolute vs. relative, static vs. dynamic, and whether its a path, gateway attribute, or both. Also whether the metric is dimensioned or dimensionless. There was consensus at the last meeting that this metric was not dynamic, but represented the total capacity of the gateway. There was no objection to the decision to use a dimension for the metric in order to allow vendors to independently set the metric and use comparable values. There was no consensus on what the dimension should be (calls, bits/sec, etc.). Unfortunately, time ran out and the next presentation began. Gateway Location Protocol based on SCSP --------------------------------------- Matt Squire, Nortel Networks http://www.bell-labs.com/mailing-lists/iptel/glp_scsp.ppt Matt presented his arguments on why SCSP was a good choice as a basis for GLP. First off, GLP is an inter-domain protocol, so one immediately thinks of BGP. However, this is not a layer 3 protocol, and there are differences, so a different approach is warranted. SCSP provides database synchronization among autonomous servers. SCSP defines a server group (SG) as a collection of servers being synchronized. The idea with SCSP is that for interdomain exchanges, the SG has two, and exactly two, servers - the two peers. For interior exchange among GLP LS's in the same domain, there is a different SG [Slide 2]. SCSP supports arbitrary topologies for this interior synchronization. The model of a GLP LS was shown [Slide 3]. Through various server groups, it learns about gateways, and based on policy decisions, propagates these to other server groups. Matt then presented the reasons why GLP is not BGP: 1. BGP must always provide a next hop on the same LAN. However, since GLP is at a higher level, there is an underlying IP transport service. So, an LS can choose to not modify the next hop at all; it can be bypassed all together for signaling. The only reasons to actually change it are for (1) aggregation, or (2) collection of billing information from the signaling messages [Slide 4,5]. 2. In BGP, if there are two routes to a destination, only one is propagated. Basically, routes are "homogeneous" - they are all the same. Not true in GLP. Routes for the same prefix may be different if their attributes (like signaling protocol) are different, and so both may need to be propagated. BGP doesn't do this. [slide 6] 3. In BGP, the FIB is extracted purely based on destination address. This doesn't work in GLP. A "FIB" would need to also look at the parameters of the call signaling to determine which route is appropriate. Thats because GLP routes call signaling messages, which are much more complex than IP packets. [slide 7] 4. Efficiency and scaling requirements differ (fewer call setup messages compared to packets) [Slide 8]. However, Dave Oran pointed out that an LS may also route voice packets. He argued that this was useful for firewall traversal, and would motivate providing next hop information in general for GLP, for both signaling and media (next hop at the layer 7, GLP, definition). Next, Matt argued why SCSP was a good choice: 1. SCSP separates the synchronization of data from the semantics of the data itself [slide 9]. This is perfect for GLP, where we need a generic sync mechanism, and then need to add GLP specific attributes and data on top. SCSP was designed to be a "core" component, with instances defined for specific applications. 2. SCSP supports arbitrarily connected topologies for intra-domain synchronization [slide 10] 3. SCSP can run on any transport [slide 11] There was little discussion at this point; most of it followed the presentation on TBGP. Telephony Border Gateway Protocol (TBGP) ---------------------------------------- Hussein F. Salama, Cisco, hsalama@cisco.com Quick TBGP overview [Slide 2] - based on BGP-4 and its multiprotocol extensions - reliability, peering relationships, loop detection mechanisms - advertised reachability of PSTN destinations and IP destinations - multi-hop call routing. egress gw is just another hop on call route - route selection. intermediate domains apply policy on call route network admin control route selection - route aggregation BGP itself does not solve all the GLP problems. We propose an extension sthat taskes care of additonal needs. The first question is whether TBGP and BGP4 are the same (i.e., do we introduce telephone numbers into existing, running, BGP-4 systems). Answer is NO. TBGP runs separately from BGP4. But, we leverage experience from the specification to make a good protocol [slide 4]. TBGP supports multiple protocol types (SIP, H.323), route aggregation, route selection etc. How to handle the case where the media flows through the LS? [slide 5] Dave Oran then proposed a scheme for dynamic capacity metrics. The idea is that when a gateway has used all its capacity, it withraws routes to itself with its peers. When it has capacity, it puts it back. Normally, you need route-dampeners at next hops, so some of this oscillation would be avoided. This provides a way to propagate a sort-of-dynamic metric, but in a more scalable way. There were concerns raised about the scalability of this solution, and no consensus was reached on whether to do this. Hussein then discussed the Intra-domain vs. inter-domain call routing scenarios [slide 7]. He argued that these are much different problems, and that intra domain worries most about QoS and multihop call routing, while inter-domain worries about policy and cost, and QoS is much different. Thus, he countered the argument that SCSP was good since it helps solve the intra-domain problem. We should leave the intra-domain problem to another group, and weigh the protocols based on their ability to do inter-domain. The remainder of Hussein's slides focused on attribute issues, and since these were discussed already they were skipped. Concusions - TBGP satisfies all tranport requirements of the GLP framework - attributes are yet to be defined - well tested and scales well - we know how this works! - intra-domain call route is a separate problem Jim Luciani argued that SCSP's strength is to allow for arbitrary topologies, and that it could handle intra-domain QoS issues. Someone argued that since SCSP was similar to OSPF, it wouldn't handle things like AS path, which were needed in an inter-domain case. This was countered with the argument that we could make AS-path just another attribute that gets synchronized by SCSP between peers, and get this functionality. Another strength of SCSP was that the nodes that are synchronized don't need to understand the semantics of the data being synchronized, that is handled by the higher layers. The question was asked as to whether there were commercial and interoperable implementations of SCSP. The answer - yes, they are out there, and yes they are commercial. It was concluded that in the inter-domain case, the type of information being carried by BGP and SCSP would be similar, and thus the differences between the protocols was at a much more detailed level. To resolve the issue, the chair asked the authors to do a "homework assignment", and work on understanding detailed differences between the two proposals. This will then be taken to the list. At this point, the group left discussions of the GLP, and focused on the CPL. The first presentation was on transport. CPL and CGI Transport in SIP Register Paylaod --------------------------------------------- Jonathan Lennox, Columbia University http://www.bell-labs.com/mailing-lists/iptel/sipreg-minneapolis1.pdf Jonathan quickly went over his slides. The basic idea was that the CPL is uploaded to the server in a REGISTER message. There is a single server per user. The main issue is persistene. Normally, a SIP registration times out, and disappears unless refreshed. But, CPL's would not time out. They would be uploaded once, and never re-uploaded when the registration itself is refreshed. This generated some discussion about whether this model was right. One idea (Gur Kimchi) was that the REGISTER contains a script for the client, and when it registers, that script is used. When the client goes away, and the registration expires, so does its script, and then we use the script that was previously in place. Scott Petrack argued as to why do this in SIP at all? Why can't I use ftp, or http, or whatever? Clearly REGISTER was not meant to send user logic to a server. The answer was that SIP provides much of the transport service we need. It gives authentication, it uses the same identifiers we need to tie the script to a user, and its the same application. However, there was agreement that there need not be a single transport mechanism. Another issue was whether the "one-script" model is sufficient. We may need more. Jonathan R. raised the concern, however, that if more than one script exists, how would the server know which to execute when the call arrives? Rather, there is a single top level script, and the user can upload multiple files which get linked in to the script at specific points. This is really mutiple files, still a single script though. Dave Oran raised an important issue - that there is a difference between a *user* and a *client*. The client is one instance of the user. Both clients (like my cell phone or work PC) and users may have logic they'd like to upload. So, the framework should allow for scripts for users and clients. Scott Petrack added further that a single user may have multiple scripts, each at a different server. Jonathan Lennox then continued with his presentation, focusing on some of the open issues. It was suggested that even SNMP might be used for transport, and that the MIB specifies the script. Given the various options for transport, there was consensus that the transport problems should not be tackled in iptel. Rather, if someone wanted to use protocol X for transport of CPL, the CPL transport would be done in the group specifying protocol X. Jonathan Lennox was asked to repeat his presentation to mmusic for this reason. The next presentation was on the CPL itself. Call Processing Language ------------------------ Jonathan Lennox, Columbia University http://www.bell-labs.com/mailing-lists/iptel/cpl-minneapolis1.pdf Jonathan began by showing that the CPL model is based on a DAG (directly acyclic graph), which describes the flow for a service. Each node is a decision or an action, and the outputs represent decision results or action results [slide 2] He then summarized the features [slide 4]. There are switches for making decisions (based on time, or by string matches of fields in the request messages), and actions, such as proxy, redirect, and respond. There is also a location action for setting the destination of a proxy or redirect, and a lookup action for querying a database. There are also non-SIP actions, such as notify and log. Scott Petrack raised the issue about whether XML is an efficient representation. Jonathan L.'s response was that the XML is for transmission. Once it arrives at the server, it is parsed and stored in some internal format which can be efficiently executed. Thus, the parsing overhead is suffered only on registrations. Gur suggested a binary representation instead. Gur also asked if the script is persistent during the call. The answer was not in this version; the script is "done" once the call is established. We have left hooks for future scripts to specify services after the call is established. Matt Cannon asked if the script could specify logic for OPTIONS. Right now, no; but this could easily be added. Another question was whether the CPL should support decisions based on media types for the call (audio, video, etc.). There seemed to be consensus that this was a good thing to have. Jonathan then continued with the open issues. URL matching is currently done by string matching, which is nicely general but not very efficient, and it is hard to do certain things. Supporting URL specific decisions means that the script may no longer be H.323/SIP independent. Time switches also presented problems. Timezones are especially difficult, since there is no registry of names for timezones. So, the CPL assumes that the user and server sit in the same timezones. A question was asked as to why not just represent timezones as an offset from GMT? The answer is daylight savings time makes this offset variable. Jonathan L. asked the question about whether CPL should be configurable about whether to do recursion. Dave Oran responded that this stuff is really new, and we should absolutely stick with KISS, get something out the door, get some operational experience, and then build on that. So, the answer to the original question seemed no - there was consensus that specifying SIP recursion or not was outside the scope of CPL. With that, the meeting concluded.