Subject: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!)

From: Dean Willis <[email-masked]>
Date: Fri, 5 Mar 2010 14:04:58 -0600

Fundamental routing problem:

The fundamental SIP routing problem is this: I've been given a message  
that is addressed either to a telephone number or to a user@domain  
name. Where do I send this SIP request to next?

For "really stupid nodes", the question is easily answered: if the  
destination isn't "me", I send the request to my default proxy and let  
it deal with the problem. The default proxy might route the message  
itself, or it might send back a 302 informing the me as to where to  
send the request. It is important to note that in general, this "next  
hop" decision represents a singular hop. We have no way to 302-respond  
with a vector that specifies a sequence of relays to be used.

For a smarter host on "the open Internet", the answer is also easy. If  
the target identifier is a "user@domain" URI, then I look up the  
domain part in DNS and send the request there.  If the target  
identifier is a phone number, I use ENUM to look up an associated SIP  
URI, and I send the request to that URI. Local routing tables that  
have much the same effect may also be used, but are not specified in  
the governing RFCs.

But the "real world" (at least as we have allowed it to become  
perverted) doesn't work that way. In this unhappy place, we don't have  
direct end-to-end SIP routability. Instead, for many reasons good,  
bad, and mostly practical, we must transit a set of relay nodes to get  
from point A to B.  Further complicating matters, we may not even know  
what the whole set of nodes are, as various portions of the vector may  
be "topology hidden."

So in practice, a "really stupid node" like a phone-gateway or PBX  
sends its request to a routing proxy, which then uses a combination of  
ENUM, DNS, and local policy to select a next-hop relay. Note that this  
decision-making process tends to repeat at each relay node, since 1)  
we don't have away to represent a multi-hop vector in a 302 response,  
and 2) each node has limited view of the end-to-end visibility, in  
part due to topology hiding. There's no good exchange mechanism for  
this information, and no standard way to inform SIP nodes about how to  
use it. We've seen proposals for source-context-sensitive private ENUM  
solutions, mutagenic SIP proxy servers that return 302s, various web- 
service approaches, and others.

TRIP: A solution?

TRIP proposes one model, wherein the "smart" nodes (called LS, or  
Location Servers) exchange reachability information with each other  
using a variant of BGP. This provides us a rich fabric for advertising  
routes, control peering policy, deciding what parts of stuff to  
"topology hide", and so on. Where BGP uses IP addresses (or the  
prefixes thereof) as routing targets, TRIP uses telephone numbers (or  
the prefixes thereof). Like BGP, it allows for "internal" routing  
using a flood model, and "external" routing using more controlled  
policy.

In shortest essence, TRIP allows a first LS to say to an external LS   
"For the following phone numbers and phone number ranges, I suggest  
you use this other node or set of nodes (by IP or DNS name) as your  
next hop(s). And  I heard this from node X, who heard it from node Y,  
who heard it from node Z."  It allows allows a first LS to say to its  
internal peer "Here are all the routes I know; feel free to use them  
and please tell me about any you know that I don't."

But TRIP has not caught on. I've heard mixed answers, which boil down  
to 1) its aggregation model for routes is broken, meaning Too Many  
Routes (as a product of LNP which makes phone numbers messy), 2) it's  
too complicated, and 3) Cisco owns the IPR, and I'm not sure they want  
to share. I'm not sure I believe this is all there is to it.

The REAL problem with TRIP may be its fundamental routing model. It  
assumes that the routing of a phone number is a property of a given  
phone number (or aggregation range), and doesn't capitalize on the  
actual peering relationships. Further, it doesn't really allows us to  
talk about "routes to domains". just "routes to phone numbers", so it  
doesn't help with a call to "sip:[email-masked]" at all. And as we  
know,  given the peering models, RFC 3263 is also inadequate for "sip@[email-masked] 
". We can't go from here to there using "example.com"'s SIP SRV  
record. Instead, we need to find the right peering partner who can get  
us there, and we don't have a good way to do that.

Another model: Inter-ITAD routing:

If we assume that each SIP Service Provider (SSP)  is essentially the  
same thing as an ITAD (Internet Telephony Administrative Domain), and  
that ITADs peer with each other along well-defined channels (using  
Session Border Elements, SBEs, known by other acronyms including  
Little Spawns of Satan etc.), then this gives us another routing  
topology to consider.

Assume a routing protocol that tells ITAD A that to reach ITAD Z, the  
request should be sent to ITAD Q (or perhaps to a vector of Q and T)  
who will act as an intermediary. If ITAD A can directly reach Q, then  
A knows how to route the request. A can send the request to A's SBE  
that is adjacent to Q, which then hands it to Q's SBE (adjacent to A),  
which then consults its own routing tables to figure out how to move  
the request on, either to Z, to the previously declared secondary  
route T, or to some other ITAD known to Q that will serve as a relay.

With this model, we don't need to know the route for a given E.164  
number (or @domain part). All we need to know is which ITAD that  
target is associated with. We then consult the ITAD routing table to  
send the request. This means that the largest dynamic routing table  
required is the inter-ITAD map, which is exponentially smaller than  
the number of telephone routes.

So, given a dynamic inter/intra ITAD routing protocol that can tell us  
what SBE to use to move towards a given ITAD, all we need to know is a  
way to translate a phone number or a domain-part into an ITAD.

This is the easy part. ENUM gives us an excellent mechanism for  
turning phone numbers into either numeric or domain-style ITAD  
identifiers. The mapping of phone number (or phone number range) to  
ITAD is relatively static, globally valid, and well-suited to the  
recursive-lookup and cache model that ENUM inherited from DNS.

This gives us a new simple model for call routing at the LS for phone- 
number targeted calls

1) If the number isn't locally known, look up its ITAD in ENUM. This  
might be range-matched or fully qualified; it's just a standard ENUM  
lookup.
2) Consult the ITAD routing table to select an SBE (and possibly  
additional transit ITADs) to find the routing vector consisting of one  
or more SBEs and zero or more transit ITADs.
3) Canonicalize the request URI and add the SBEs/ITADs as loose route  
hops
4) Send the request.

For domain-targeted calls, we might also get to add in "Check to see  
if the destination is reachable via RFC 3263, and if so, use that"  
somewhere in the process.

The short form of this model is 1) Find the ITAD of the destination.  
2) Find a route to that ITAD (which might be one or more  
intermediaries. 3) Send the request there.

Conclusion:

So, other than a dynamic routing protocol that meets inter/intra-ITAD  
routing requirements and could be derived from TRIP (or built using  
some other model, such as a SIP event package), what are we missing?

--
Dean

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 05 Mar 2010 14:30:00 -0600

Dean Willis wrote:

> This is the easy part. ENUM gives us an excellent mechanism for turning
> phone numbers into either numeric or domain-style ITAD identifiers. The
> mapping of phone number (or phone number range) to ITAD is relatively
> static, globally valid, and well-suited to the recursive-lookup and
> cache model that ENUM inherited from DNS.

Define 'relatively static' in this context... With LNP in North America
at least, there are thousands upon thousands of phone numbers being
moved from one provider to another every week day.

> This gives us a new simple model for call routing at the LS for
> phone-number targeted calls
> 
> 3) Canonicalize the request URI and add the SBEs/ITADs as loose route hops
> 4) Send the request.

It is my understanding that at the SS7 level in areas where LNP has been
deployed, the initial route for any number is still the provider who was
assigned the block containing that number; if the number has since been
ported, that provider's switch will reply with what is effectively a 302
to the new provider servicing that number. This was done because of the
same reasons you are talking about here... a routing table that could
route to the phone-number level would be enormous.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Mar 2010 15:10:18 -0600

On Mar 5, 2010, at 2:30 PM, Kevin P. Fleming wrote:

>> turning

Yep, and there are hundred of thousands of DNS records changing every  
day. This is still handily in the design-model for DNS.

> route to the phone-number level would be enormous.

Hmm. I thought we were doing LNP dips for every phone number on call  
setup. Since the proposed ENUM dip handles both ported and non-ported  
cases, it seems like this would work well. Although it should be  
pointed out that porting MAY still send the call to the original ITAD  
for service until the TTL has exhausted, so the original ITAD has a  
little more work to do when effecting a port than just update one ENUM  
record.

--
Dean

---

From: [email-masked]
Date: Mon, 8 Mar 2010 09:39:41 +0000

Dean,

Please see attached an (unsubmitted) draft I started writing a couple of 
years ago before DRINKS really took off (in the wrong direction, IMHO).

The bilaterally exchanged information described there in could be your 
ITAD routing system.  What this does have (but your notes don't have) is 
the concept that an ITAD actually needs to be broken into smaller parts to 
achieve optimal routing.  At least in the EU/UK, carriers like "far end 
handover", because it's cheaper to keep the call in your own network and 
drop it into the recipient network as close to the called party as 
possible.  This more fine-grained split is the "destination group" term 
now used in DRINKS.

kind regards,

Ray