Subject: [IPTEL] iptel-gwreg-req open issues

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 30 Nov 2001 14:14:48 -0600

A few comments on the open issues listed in the draft.

REQ 6- I think this is a real requirement. I think that in many complex
architectures (such as ones in which MGCs are used as gateways), the
provisioning of ranges of POTS numbers associated with gateways must be
performed in multiple locations (proxy servers and gateways, at least) if
there is not some sort of gwreg mechanism that allows you to provision in
one place and then automatically propagate the data to any other systems
that need it. In my opinion, simplifying provisioning is one of the primary
reasons to use gateway registration. If you have to substantially
pre-provision proxies then I don't think gateway registration makes your
life that much easier.

As a side note on 6, I'd like to say that I agree with Jonathan that
(monetary) cost should not be considered at this time, especially since
settlement is poorly understood overall in the VoIP community and the
construction of some sort of attribute that expresses monetary cost does
seem to be a labyrinthine rat-hole. But it's also important to acknowledge
that every trunk that goes to a PSTN switch is potentially a route to every
E.164 number prefix - reachability of POTS number addresses in the PSTN is
(with only some obscure exceptions) ubiquitous. By associating E.164 number
prefixes with routes we are introducing an artificial, administrative
restriction on the traffic that uses a route - we are expressing a sort of
preference. The primary reason why carriers do so is because the cost of
terminating a particular E.164 range over a given trunk may be especially
favorable. In this sense, I think that the idea of LocalPreference (and to
some degree monetary cost) is built-in to the idea of routing by E.164
ranges. Under duress (due to congestion or failure on more desirable
resources) most carriers would override these restrictions and route other
traffic over such trunks.

REQ 8- I really think the gwreg protocol should be extensible, even if we
aren't sure how we'd like to extend it at the moment. As for whether these
attributes are attributed to routes or gateways, I'd actually suggest a
third alternative for consideration - trunk groups. My carrier architecture
provides a few examples of how such dynamic data depends on trunk groups
rather than gateways.

REQ 11- I'm not sure I entirely understand either the requirement or the
open issue here, but I'll take a stab at this. Since we're considering gwreg
in the absence of intradomain route propagation, independent routing
policies amongst multiple proxies in an ITAD seems like an unlikely issue to
address - any system in which there's a possibility that there are
independent proxies that could somehow be synchronized requires something
like routing policy centralization or intradomain propagation.

Is the assumption here that if there are multiple proxies in an ITAD, that
some gateways register with one proxy, and some gateways register with
another, perhaps depending on a POP at which the gateways are located?
(Also, is there a latent requirement here about the cardinality of the roles
of gateways and proxies?) Clearly if two proxies in an ITAD do not
communicate with one another, and each gateway registers with a single proxy
at a time (discounting failover), then I don't think it would even be
possible for two proxies to return the same decision. If allowing something
along these lines is what this requirement signifies, then I definitely
support it.

On another angle of this, perhaps support for some sort of load-balancing
should be its own requirement, since I'm not sure that's entirely dependent
on multiple proxies - I'd suggest that a single proxy should be capable of
returning different routes for two calls targeting the same address if it
has received multiple gateway registrations matching the parameters of the
call that have the same preference. Nor do I understand why a database
protocol would preclude load-balancing...

REQ 12- I'm not really sure why this sort of 'discovery' would be needed. I
agree that static configurations are more likely. Also, I  envision that
either the gateway or the proxy could initiate the connection. For the sort
of architecture I have in mind, it would make more sense to statically
configure the gateway with one or more proxies (each probably associated
with a preference) to which the gateway would attempt to connect.
Cryptographic authentication could let the proxy guarantee that the
connection is desirable.

Jon Peterson
NeuStar, Inc.

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