Location Routing Function Requirements Hadriel Kaplan

The Setup SIP Request originated at Enterprise-1 to SSP-A What will this request URI look like? 2.tel: For URI’s 1+2, an LUF function is needed, to determine terminating SSP-ID For 3, no LUF is needed

The Problem Let’s assume LUF determines the terminating domain/SSP is SSP-E How does SSP-A get there? SSP-A may not have a pre-existing relationship with SSP-E –Not peers –Not in same Federation/Registry-zone Today’s answer: PSTN for E.614, URI’s rejected DRINKs should figure out something else

Another Problem The size of some SSP’s is large – hundreds of SBE’s –Currently 4 SSP’s have over a hundred each –Topology changes are relatively frequent The SBE-routing relationship is complicated –Not all SBE’s connect to all peers –Some SBE routes are preferred based on source, for both hot-potato and cold-potato models

A Potential Problem -style URI’s: Are they real? Will they be? –Some people think so Won’t they be routed direct? (rfc3263) –Maybe, maybe not

The Solution A dynamic location routing protocol Not TRIP –Many problems, and it’s dead Not ESPP –Not the right architecture, and don’t need to complicate ESPP’s LUF role –But we could reuse ESPP’s syntax We need to start with requirements

Example Requirements R5: The LRF mechanism MUST dynamically discover failures, and provide alternate routes around failures if such routes exist R6: The LRF mechanism MUST support restricting the originating domains which can use or learn routes. R7: The LRF mechanism MUST allow a SSP to select routes to use based on its own selection preference criteria, which may or may not be the same criteria other SSPs use

More examples… R13: The LRF mechanism MUST NOT require an SSP to reveal internal SIP topology information to external SSPs. R14: The LRF mechanism MUST NOT prevent migration to or co-existence with [RFC3263] direct-routing Read the draft for all of ‘em