NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99
Jonathan Rosenberg <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Vern Paxson <email@example.com>
Transport Area Advisor:
Scott Bradner <firstname.lastname@example.org>
To Subscribe: email@example.com
Description of Working Group:
Before Internet telephony can become a widely deployed service, a number of protocols must be deployed. These include signaling and capabilities exchange, but also include a number of "peripheral" protocols for providing related services.
The primary purpose of this working group is to develop two such supportive protocols and a frameword document. They are:
1. Call Processing Syntax. When a call is setup between two endpoints, the signaling will generally pass through several servers (such as an H.323 gatekeeper) which are responsible for forwarding, redirecting, or proxying the signaling messages. For example, a user may make a call to firstname.lastname@example.org. The signaling message to initiate the call will arrive at some server at bigcompany. This server can inform the caller that the callee is busy, forward the call initiation request to another server closer to the user, or drop the call completely (among other possibilities). It is very desirable to allow the callee to provide input to this process, guiding the server in its decision on how to act. This can enable a wide variety of advanced personal mobility and call agent services.
Such preferences can be expressed in a call processing syntax, which can be authored by the user (or generated automatically by some tool), and then uploaded to the server. The group will develop this syntax, and specify means of securely transporting and extending it. The result will be a single standards track RFC.
2. In addition, the group will write a service model document, which describes the services that are enabled by the call processing syntax, and discusses how the syntax can be used. This document will result in a single RFC.
3. Gateway Attribute Distribution Protocol. When making a call between an IP host and a PSTN user, a telephony gateway must be used. The selection of such gateways can be based on many criteria, including client expressed preferences, service provider preferences, and availability of gateways, in addition to destination telephone number. Since gateways outside of the hosts' administrative domain might be used, a protocol is required to allow gateways in remote domains to distribute their attributes (such as PSTN connectivity, supported codecs, etc.) to entities in other domains which must make a selection of a gateway. The protocol must allow for scalable, bandwidth efficient, and very secure transmission of these attributes. The group will investigate and design a protocol for this purpose, generate an Internet Draft, and advance it to RFC as appropriate.
Goals and Milestones:
Submit gateway location framework document to IESG for consideration as an RFC.
Submit call processing syntax framework document to IESG for consideration as an RFC.
Submit call processing syntax document to IESG for consideration as a Proposed Standard.
Submit gateway location protocol document to IESG for consideration as an RFC.
No Request For Comments
Minutes of the iptel meeting
Thursday, July 15, 1999, at 1300 - 1500
IETF 45, Oslo, Norway
Minutes Prepared By: Jonathan Rosenberg
Minutes Taken By: Hui-Lan Lu, Wilhelm Wimmreuter, Jonathan Rosenberg, Hussein Salama
The meeting began with a presentation of the agenda. The proposed agenda was:
Agenda Bashing [Rosenberg] 5mins
CPL Framework [Rosenberg] 5mins
GLP Framework [Rosenberg] 5mins
IN for SIP [Gurbani] 10mins
GLP Attributes [Squire, Salama, Rosenberg] 1hr
GLP sync/transport [Rosenberg] 35mins
The agenda was accepted.
An updated version of the CPL framework document has been submitted. There are no significant changes to the model itself, but the document has been trimmed and cleaned up. Some of the changes are:
· focus on the framework, and less on requirements (thus the renaming of the draft)
· trimming of services based on KISS. The services that remain are all call routing related, pre-call services.
· Scripts represent addresses - these can be users, terminals, or groups.
There are still some open issues and things to be done:
· what server to upload a script to
· reorganization of the document for clarity
The document is scheduled for last call in August. Send comments!
An updated version of the GLP framework document was submitted, and a wg last call issued on it. The document represents significant editorial changes, but nothing new to the framework itself. Some of the changes include:
· much more detailed problem definition
· comparison to related problems (i.e., enum)
· example applications
· section on differences/similarities with BGP4
· discussion of 800 number issues, as per wg consensus at the Minneapolis meeting
· LS model added
· improved front end description
There were minor comments submitted since the wg last call. These have been incorporated, and a new version will be submitted shortly. The chair indicated that IESG last call would begin right away, but Vern indicated that there is no IESG last call needed for informational documents. For this reason, the chair extended the wg last call period for the week following the IETF.
An important comment was raised by Scott Petrack regarding internationalization. The framework document refers to concepts like "800 numbers", which are distincly American, as opposed to the more generic freephone. Scott invited comments from non-Americans to make sure the document was internationally-friendly.
SIP and IN
There was a presentation from Vijay Gurbani on SIP and IN. Slides can found at http://www.bell-labs.com/mailing-lists/iptel/gurbani-in-jul99.ppt. The basic idea is that we'd like to be able to access traditional IN services (like freephone, caller-ID, LNP, call screening, etc) from SIP networks. This allows us to leverage existing equipment and services, and to provide new, converged services. In order to do this, you need to overlay an SSF (service switching function) ontop of the SIP server. Vijay proposed overlaying the IN call model ontop of the SIP state machine. He proposed a mapping from the states of one machine to the other.
Some questions were raised concerning what components were addressed. Was SRF addressed? What about the call state view (CSV). Vijay indicated that those were not, but they could be included. Igor Faynberg felt that the services discussed did not require inclusion of the CSV. Christian asked how the SIP server would know which SCP to contact, and how security would be handled.
There were several comments which indicated belief that this work belonged in ITU or ETSI rather than IETF. The work requires expertise in call models that is not present in IETF. The chair added that it should be made clear that the presentation was informational; it was not meant to be a proposal for new work for iptel at this time. People interested in the work should contact Vijay offline, and could discuss the appropriate fora (ITU, IETF or ETSI) for continuing the work.
- Matt Squire presented joint work between himself, Hussein Salama, and Jonathan Rosenberg, in an attempt to forge consensus on the common parts between the TBGP and SCSP based solutions from the past meeting.
- The first issue is flags. We have a number of flags we need, many of which come from BGP. They include optional (don't need to understand it), partial (not everyone has understood this attribute), independent-transitive, dependent-transitive, and non-transitive. Dependent transitive is new, and means the attribute must not be passed on if you don't know it and have modified the next hop, otherwise, it can be passed on. This is because an LS need not modify the next hop. The OPEN ISSUE is: is this the right set of flags?
- Another issue is how to aggregate unknown attributes with independent transitive flags. We can say that the attribute should be passed if it is the same binary value in both routing objects. Or, we could define classes of aggregation rules, like add, union, max-min, and so on. OPEN ISSUE: what to do?
- The first attribute he discussed is signaling protocol. This includes the protocol (SIP, H.323), ISUP flavors, UDP/TCP, and port numbers. One open issue is whether H.323/RAS and H.323/Q.931 should be split into separate protocols. Tom Taylor felt there was no need to split RAS out, since it is not run to gateways. There seemed to be general consensus for this, so H.323/RAS will not be a separate protocol.
- Another issue was ISUP flavors. Lyndon Ong commented that there was some preliminary work on an ISUP flavor registry. Scott Petrack preferred to keep ISUP flavor registration out of IANA. It was asked that if anyone knew of existing registries of values of ISUP flavors, to bring it to the list. Finally, the chair asked about whether people thought ISUP should be a "top level" protocol, on par with SIP or H.323, or should be a parameter of SIP/H.323. There was no comment on this issue.
- The next attribute to be discussed was pricing. It provoked many comments. The first issue was a registry for currency codes. We don't want to define one; there must be one already. Douglas Clowes commented that ISO 4217 provides a listing of currency codes. Another issue was representation of monetary units. The current wording says floating point. Dave Oran mentioned a number of problems that arise from this. There seemed to be consensus for a fixed point representation instead.
- Christian Huitema raised an issue about usage of the pricing attribute. Does it represent a contractual agreement (i.e., if it says 5 cents a minute, is that a guarantee of that pricing?). The answer was no - this information is used for routing selection, and not contractual. In this case, Christian indicated that pricing is probably guided by a contract somewhere else, and as a result, there is no need to carry this cost information in GLP. Rather, it can be a token that has significance between peers, referring to some parts of a contract or something like that.
- It was then suggested that we change this from a "pricing" attribute, to a "cost" attribute, to better indicate its purpose. There seemed to be agreement to do this. There was also a suggestion to allow time of day based variations in cost. It was mentioned that at the last meeting, there was agreement, based on KISS, not to do this within the baseline protocol. One way to support this is to add and withdraw routes at the appropriate times of change. This works for time of day costs which aren't too dynamic. If more dynamism is needed, a new cost structure could be registered with IANA, which contains information on temporal variations.
- Finally, it was emphasized that the cost attribute is a peer to peer attribute. It is NOT end to end. If A advertises a route to B for cost X, C can re-advertise that route to its peers at any cost it wants. Likely, the cost will be equal or more to the amount it is being charged by A, but that is B's discretion.
- There was not clear consensus about whether an opaque token or a cost structure is desired.
Last Modified By-
- The next attribute discussed was LastModifiedBy. The idea with this attribute is that authentication can be more than one hop away, since an LS need not modify attributes. You'd like to be able to authenticate the last hop which modified a routing object. The main open issues is whether we should allow multiple LastModifiedBy's, for various attributes. Brian Rosen commented that you don't want to remove old authenticated data, that it should all be included for complete path security. Matt commented that this is at odds with aggregation, however.
- A comment from the group indicated that this definition might make the attribute transitive. Matt responded that non-transitive means "don't pass this on if not understood", and this is definitely confusing.
- Hussein continued the discussion on attributes with a presentation on path attributes. He discussed advertisement path, which is the path that the routing advertisement, via GLP, follows. Christian pointed out that the example picture Hussein used was not a good example of this concept.
- The next issue is NumSignalingHops, which is a subset of the LS's in the advertisement path. It is aggregated with a max/min aggregation function. An alternative is for a signaling path attribute, much like advertisement path. It would be useful for source routing (supported in SIP), and for policy decisions. There seemed to be consensus to use signaling path rather than a hop count.
- An important issue was then raised regarding attributes which cross RIBs and represent disjoint paths. There was a lot of confusion about exactly what the problem was, but it appeared related to the fact that route selection depended on more than just the destination phone number. It was decided to take the issue to the list.
- Hussein then presented the Atomic Aggregate, Local Preference, and Multi Exit Discriminator attributes, which are largely identical to their BGP equivalents. Someone commented that the origin attribute was not present, and that it was found useful in BGP for route selection among equal cost paths. Hussein responded that you could gleam this information from the AS path; there was no consensus on whether this was sufficient. It was agreed to take it to the list.
- Jonathan then presented the gateway attributes.
- The first of these is capacity, which represents the number of calls a gateway can handle. He presented some equations which allow the information to be aggregated. Tom Taylor pointed out that megaco is facing a related issue, and is relying on mmusic to provide with a solution. Lev Slutsman commented that the number of calls the gateway can handle is not sufficient, and that a metric such as erlangs is more appropriate, particularly for traffic analysis. Jonathan responded that actual gateway capacity is actually quite complex, and is dependent on MIPS, memory, PSTN access, IP connectivity, and so on, and is too hard. Using the KISS principle, we want just a simple metric to use to compare gateways. Calls is about as simple as you can do.
- Christian commented that this attribute had no equivalent in BGP, and was not useful and not needed.
- Jonathan commented that another use for the capacity attribute is load balancing, done in proportion to capacity. He raised some issues about the possibilities of looping when load balancing is done. Comments from the group indicated that there really is no problem; BGP policy correctly prevents loops even when load balancing is done.
- It was agreed to take it to the list about the usefulness of capacity.
Destination Phone Numbers-
- The next attribute was desination phone number. The current wording defines it as a traditional prefix, with bytes per digit, represented as a char. Aggregation requires 10 routes, but possibly less if the LS knows about black holes. These black holes are not explicitly advertised. Jonathan presented an alternate, bitmask representation, which allows phone numbers to be represented efficiently, and providing the same flexibility as glob matching with the  and * rules. He also presented rules and equations for aggregation and longest prefix match.
- There seemed to be consensus that this was too complex and not worth it. Jonathan presented a compromise approach, which uses normal prefixes for the phone number except the last digit, which uses a bitmask. This allows two prefixes to be aggregated, but maintains the simplicity of normal prefixes. There was some nodding that this seemed OK, but no clear consensus.
GLP Synchronization and Transport
- Jonathan Rosenberg discussed synchronization and transport issues. At the last meeting, there were two proposals. One was BGP-based, and the other SCSP. They differeed mainly in regard to transport and synchronization. Since then, the authors and the chair have gotten together, and decided on a compromise approach that uses the best of both worlds.
- It was agreed among the three to the following:
· usage of TCP for transport (it works, and avoids the transport rathole)
· Usage of phone number prefix and signaling protocol as index to GIB, rather than key as in SCSP
· Usage of BGP HELLO machine for peering initialization (nearly the same in SCSP; NBMA stuff not needed anyway)
· Route withdrawing done explicitly as in BGP (not clear how it works in SCSP)
· I-GLP topologies can be arbitrary, as in SCSP, rather than full-mesh or route-reflected as in BGP. This will require us to add a few attributes from SCSP to avoid loop detection.
· Message encoding follows TLV, as in BGP.
· Add capabilities negotiation, based on recent drafts for BGP. Besides security parameters, its not clear what to negotiate.
Matt emphasized that there is no draft yet, and the above represents a dinner time compromise.
The main open issues are the details of the protocol, and how to treat the case when a peer goes down. If the peer is not the next hop of a route, the route may still work even though the peer is down. There seemed to be consensus to be safe, and discard the routes when the peer goes down.
The meeting was then concluded.