Subject: Draft of meeting minutes

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Sep 1998 16:42:33 -0400

Folks,

Enclosed are a draft of the minutes of the iptel meeting in Chicago.
Please let me know of any omissions or errors.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

Minutes of the iptel wg session at the 42nd IETF, Chicago, IL
8/24/98

Notes By: Francois Menard
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 (2) 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.

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. 

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.