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.