Re: [drinks] Comment on today's drinks discussion

[Otmar Lendl <[e-mail]>]

PFAUTZ, PENN L, ATTCORP wrote:
> 
> I've had a lingering concern about the disconnect between what Speermint
> has proposed (LUF/LRF)and the route that drinks has taken. Since the
> will of the design team seemed to be to get on with a simple protocol
> directed toward provisioning DNS RRs I let that ride. Monday's session,
> however brought up things like more abstraction of routing elements
> which suggests to me assumptions about the nature of interconnections
> and my issues with the original ESPP I-D.
> 
> Brian Rosen's comment about number "ownership" relations also seemed to
> suggest another complexity that the protocol would try to incorporate. 
> 
> I get concerned about a protocol that either makes a lot of specific
> assumptions about the nature of the registry and the interconnection
> framework and/or becomes bloated by trying to incorporate the panoply of
> possible cases.
> 

Penn,

one of the problem I see is that these assumptions regarding the
"interconnection framework" are never spelled out. I don't see a vision on
how this might all fit together other than in very restricted situations.

Anyway, on a recent train ride I tried to write up a summary on what bugs
me about the Speermint/Drinks design. Here it is:

--------------------------------------

Some comments on the direction Speermint and Drinks are taking

First of all, why do we need these WGs at all? The quick answer is that
VoIP interconnection based on plain SIP and ENUM did not work out as
envisioned by the authors of the respective RFCs. There are a number of
reasons for that (see draft-lendl-speermint-background), and I don’t expect
that the IETF can do anything to change this.

What happens in the ITU/ETSI/3GPP area? The PSTN interconnection used to be
simple before the era of telecom liberalization: you had one incumbent per
country and close to a full mesh of interconnection links between all
countries. In the GSM world, the possibility of roaming led to a large
number (scaling with O(n*n)) of contracts between operators. In both the
fixed line business, as well as in the mobile telephony world, the number
of operators has markedly increased over the last years. A full mesh of
links just is not possible any longer. Even if the underlying network does
not need dedicated links any more, just doing contracts between all
possible pairs is no longer a viable option. Recent developments in the GRX
and IPX demonstrate this: The introduction of "hubs" was necessary to get
the quadratic scaling under control. The time of full meshes is over.

Call routing was rather simple in the full mesh world (be it PSTN or
RFC3263 SIP), it only needed some directory service to map Public
Identities (PI = phone numbers or SIP URIs) to operators. In a lot of
cases, these directories are static simple mappings like "route anything
starting with +49 to Deutsche Telekom".

This is no longer sufficient. Any solution to the current world-wide call
routing problem needs to cope with arbitrary interconnection graphs, not
just the trivial case of full meshes. A directory will not suffice any
more: we need a full blown routing algorithm.

I repeat: The current graph of interconnection between carriers has no
special properties any more. We have a text-book routing problem to solve.

This is not what Speermint is supposed to solve. As the name says: It is
supposed to do “peering” and not “routing”. In other words, Speermint
covers what two operators need to do to exchange calls between their direct
customers.

As the need to cover transit is clear, it has crept into a good number of
Speermint documents. This just amounts to “we need to consider these
scenarios”, but not to “here is how you solve them”.

Why is Speermint restricted to peering? My guess is the following:

    * The driving force behind the establishment of this working group is
the set of US MSOs. Their motivation is simple: enable direct call routing
amongst them. They do not care about transit.

    * Doing a routing protocol for VoIP violates the IETF end-to-end
principle and is thus not politically correct.

    * A full routing architecture plus routing protocol for VoIP is a huge
task and to be successful needs buy-in from traditional carriers. This is
more than the IETF is willing to tackle.

    * Peering can be stacked on existing protocols as implemented in the
SIP devices: all the reachability/routing information is stored in ENUM
trees which the SIP devices query. The only protocol work relates to how
these ENUM trees get populated. Thus DRINKS.

What’s not to like?

    * Transit will be back.

      It’s an illusion that we can build a system solely for peering
setups. This will get used for transit. The foundations build by Speermint
will not be able to really support transit. I predict utterly messy and
unstable deployments down the road as transit will be bolted on peering.

      It is far better protocol design to see peering as a simple special
case of transit.

      What DRINKS is doing is the SIP equivalent of a provisioning protocol
to drive proxy-ARP servers for the interconnection of LANs. Nice and simple
if everybody you every want to reach is just a hop away, but complete
unsuitable for transit.

    * ENUM will not be enough.

      ENUM is a simple lookup protocol: The input is an E.164 number and
the result is an ordered set of service-type/URI pairs. ENUM is not a SIP
device control protocol. It is way too limited in the information the SIP
device can pack into the _query_ (e.g.: source URI, source trunk
information, SIP device ID, media requested, ...). You can fudge more
information into the ENUM _answers_ by excessive use of URI parameters, but
the query is limited by the underlying DNS protocol.

    * Excessive use of Registries.

      The LERG and LNP databases are know solutions. The default solution
for data-interchange problems in the PSTN world seems to be registries.
(Remember the old adage of a problems looking like nails when all you have
are hammers?)

      In the Internet architecture, central registries are sometimes a
necessary evil and are kept as small as possible. In the VoIP routing case,
registries are certainly part of a solution, but only to manage a shared
namespace (domain registries for URIs and ENUM registries for E.164 numbers).

    * LUF / LRF confusion.

      In a rare moment of sanity, Speermint came up with the distinction
between LUF and LRF. In a nutshell: the LUF (Lookup Function) maps the
public identifier to some aggregation concept like "destination group",
"routing key", "destination domain",... whereas the LRF (Location Routing
Function) take this Identifier as input an finds the next SIP hop towards
that destination.

      This is a common concept in the Internet: typically a domain-name is
first mapped to an IP address, and then the IP routing algorithm finds the
next hop towards the host offering services for that domain.

      The basic concept behind this is the difference between a "name"
(identifying what you want, regardless where it is) and an "address"
(identifying where something is, preferably amenable to aggregation). The
result of the LRF is the Session Establishment Data (SED) which is a
"route" (identifying the next hop towards the destination).

      The LUF is best implemented by an on-demand lookup function to
central database (which does not preclude local replicas for performance
reasons). The LUF is querier-independent; everybody will get the same answer.

      The LRF is the lookup into a local routing database. No external
database needs to be involved. But you need either a lot of manual work or
a routing protocol between the interconnection-partners to build up the
local routing tables.

    * Too much information in the Registry.

      As should be clear from the preceding remarks, I consider it to be a
serious mistake that the current DRINKS design completely merges LUF and
LRF into one single protocol.

      This overloads the registry with data that should not be there.

    * No consideration for multiple Registries.

      If registries are pure LUFs, then there are natural ways to
distribute the namespace over multiple registries: Both in the E.164/ENUM
case and the URI/domains case, the hierarchical DNS can delegate parts of
the global namespace to local registries. The actual call routing is not
affected as the LUF registries do not contain routing data. There is no
need for a registry-registry protocol to synchronize "routes" or "routing
groups".

      If the registries are mixed LUF/LRF ones, then multiple registries
lead to interesting routing problems: Unless every carrier is a customer of
every registry, then achieving worldwide VoIP routing gets tricky. Either:

          o Transit carriers re-announce PIs they learned from one registry
into all other registry they are connected to. That means that the same PI
will appear in each registry multiple times and the registry needs to
decide which path announce with what preference to carriers in need of
transit. Additionally, I don't see how you can prevent routing loops in
this scenario.

          o We invent a registry-registry protocol that avoids these
re-announcements. That just opens another can of worms: will there be a
full mesh between the registries? What kind of routing policies will the
registries implement on behalf of their customers?

    * Routing is a core competence of a carrier.

      I just cannot image the any serious transit carrier will want to
outsource its transit routing algorithm to a foreign party.

      This is not an issue as long as the registry will contain only pure
peering data.

__Summary__

Both working-groups are building a complex solution for a very restricted
special case of the generic VoIP routing problem. This will work only in
tightly restricted setups.

But it will block a clean solution for the underlying problem and will
encourage ugly hacks in the long term.

This is like designing the IBM PC with its 640kB limit while you already
know that this will lead to EMS, XMS, himem.sys and all these kludges once
you want to do more with the design than just run visicalc.

/ol
-- 
// Otmar Lendl <[e-mail]>, T: [phone] - 33, F: - 933 //