Subject: [IPTEL] gateway registration - moving forward

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Nov 2001 12:00:45 -0500

Folks,

I've been neglecting my duties as chair in helping guide the group forward
on this particular item. As you all know, I have a lot of IETF work on my
plate. Thats not an excuse, I know.

So, let me make some points on the gateway registration issue:

1. The scope of the work is clearly defined in the charter. Here is the
charter text:

---
However, this protocol does not address all the scenarios of route
information exchange between servers. One important scenario is the
propagation of routing information between gateways and the signaling
servers in front of them. This is also known as "gateway
registration". It allows the signaling server to make a routing decision
about which gateway to use based on dynamic information about
the gateway resources. Vendors have deployed proprietary solutions for this
communications interface. A standard is needed. The
group will generate a standards track document that defines a protocol
(possibly based on TRIP) for this interface. 
---

There are several key things in here. First, the charter item ONLY talks
about exchange of information between the gateways, and the servers directly
in front of them. This, by scope, EXCLUDES exchange of information between
LS/proxies within an ITAD. We are not working on the general intra-domain
problem at this time. Thus, draft-roy-iptel-itrp is OUT OF SCOPE and I want
no further discussion on this topic.

2. The charter talks about exchange of dynamic information about the gateway
resources. That is the main function provided by our protocol - not
discovery or "scale" or "reliability". Thus, it is important to focus more
time of the discussion on this issue. There were some proposals along those
lines - things like ASR and PDD, which need to be explored further. We have
also seen total capacity, available capacity, carriers, etc. I would like to
achieve consensus on a good set of these attributes, with a focus on the
dynamic ones, as thats what the charter talks about.

3. Monetary cost has come up again. I am ruling monetary cost OUT OF SCOPE.
It is a rathole and has serious issues with restricting business practice.
I'll also note that its pointless within a single domain, since cost
structures should generally be known a priori within the domain - I see
little need to have a protocol to exchange them. Protocols that do exchange
them, such as OSP, are used between different providers that have no way to
know the cost ahead of time. That is not the case here.

Henning had talked about some kind of relative, unit-less cost metrics. This
is similar to the LocalPreference attribute in TRIP, and is reasonable.
Additional discussion on this topic would certainly be welcome.

4. Much of the email discussions have focused on relatively content-free
comparisons of the protocols - mine is "more scalable" or "is easier to
interface to TRIP". These are vague and not solid enough. What we need to do
is figure out what we need from this protocol, on a concrete level, and then
we can see how the existing protocols match. For example, I would argue for
the following requirements:

  needs to have a persistent connection set up for the exchange of data, to
support congestion control

  should support establishment of a session key for authentication and
integrity; confidentiality is optional but helpful

  should support a keepalive, so that the LS can learn that the gateway has
failed. The keepalive should be fast, on the order to seconds, and not
require a lot of bandwidth (i.e., shouldn't have to refresh the entire set
of attributes as part of the keepalive)

  should support negotiation of the keepalive interval. The specific
requirement is for the server to tell the gateway what to use.

  should support partial updates, so that when a specific dynamic attribute
changes, only that attribute is sent

These are more detailed than the higher level requirements in
http://www.ietf.org/internet-drafts/draft-rosenberg-iptel-gwreg-req-00.txt,
but this level of requirement work is needed to determine what protocol we
want to use.

As Henning has pointed out, I think we will find that much of the discord on
requirements will likely come from different perspectives on the problems
that are being solved. I personally am most interested in a carrier
environment, where discovery is not needed, and where there will be lots of
gateways with lots of data to propagate. Thats different from a small
enterprise scenario, where one might want to have gateways that can be
discovered by an LS. I personally remain unconvinced that autodiscovery is
really useful in this kind of environment also, but I will post a separate
note on that. 

The main issue is this - how much do the requirements differ between these
differing environments? If we find that the discord is small, and that
perhaps auto-discovery is the only difference, that would argue for a single
solution with an optional capability to handle the differing requirement. As
Henning has pointed out, it is good to reuse a general purpose solution for
a specific scenario, if possible. This is not always possible, but it takes
requirements work to know that. If the discord is larger, that may require
separate protocols, and the group would need to decide which scenario to
address first. I would likely impose a decision based on the environement
with the smallest and simplest scope. 

Thus, I want to see the following:

1. I'd like people to post notes on the scenarios they see this protocol
being used - large carriers, enterprises, Internet2 usage, etc., and those
notes would have some diagrams of architectures along with statements of
some requirements that define that scenario. Having a common understand of
the problem areas people are trying to address is critical.

2. I'd like to see requirements posted on the functionality of the protocol,
and when those requirements are posted, I'd like to see that come with a
statement of what scenarios you believe that reuqirement is relevant for.

Once we have a fairly large set of these requirements, we can look at the
protocols on the table and see what is a match.

I'd also like to solicit a volunteer to begin edting together the scenarios
and reuqirements into a functional requirements I-D. I don't think this
would be a deliverable of the group per se, but it would help serve as a
point of documentation for whats been agreed to on the list. Please send me
a private note if you'd be interested, and have the time (the latter being
important) to do this.

I think the odds are slim that we will meet the current January deliverable
for this draft. I would propose pushing this to March, and will work with
Scott to have the charter updated to reflect that.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 27 Nov 2001 12:48:49 -0500

Jonathan Rosenberg wrote:

> know the cost ahead of time. That is not the case here.

This depends a bit on the definition of "domain". I don't think the
current ITAD definition covers the whole spectrum of possibilities. For
example, in a semi-autonomous environment, some way of advertising
prices may be useful. (Branch offices of a corporation with gateways
that handle local calls, say.)

I agree that this is not appropriate for a WG standards-track document,
but I see no harm if somebody writes an experimental or informational
RFC saying "this is how we are doing it". Thus, any protocol should have
sufficient extensibility to accomodate this. But I suspect that this is
not even necessary for what people need in this type of environment, see
below.

> Additional discussion on this topic would certainly be welcome.

I suspect that in many cases, even where some form of LCR is needed, the
unitless number will be sufficient once folks within a domain to define
what it means. Since the number is internal only, it doesn't matter to
anybody writing the protocol whether the number means thalers or simply
"don't go here unless you can't help it, we need our own phone lines".
Since updates within a domain can be frequent and people generally don't
book their phone calls like plane trips, there is no need to encode
tariffs into TLV format.

> changes, only that attribute is sent

To me, this seems less critical. Partial updates are always fraught with
danger, given possibilities for inconsistencies. This is only an
optimization that matters if the amount of data exchanged is large.
Maybe we should revisit this once we have a better idea how much data is
likely to be exchanged.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs