1 / 8

Dynamic Location Routing Protocol for SIP Integration in Network Topologies

This document outlines the challenges and requirements for implementing a dynamic location routing protocol within SIP networks, focusing on issues related to interconnectivity among Service Switching Points (SSPs). It highlights the importance of a Location User Function (LUF) for determining terminating SSPs and delves into the complexities of routing relationships among SSPs, including the inefficiencies of current solutions. Key requirements are discussed for a new mechanism that dynamically discovers failures and selects optimal routes while preserving internal topology integrity and ensuring compatibility with existing standards.

eitan
Download Presentation

Dynamic Location Routing Protocol for SIP Integration in Network Topologies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Location Routing Function Requirements Hadriel Kaplanhkaplan@acmepacket.com

  2. The Setup • SIP Request originated at Enterprise-1 to SSP-A • What will this request URI look like? • sip:+17815551212@sspa.com;user=phone • tel:+17815551212 • sip:bob@enterprise2.com • For URI’s 1+2, an LUF function is needed, to determine terminating SSP-ID • For 3, no LUF is needed

  3. 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, email URI’s rejected • DRINKs should figure out something else

  4. 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

  5. A Potential Problem • Email-style URI’s: bob@example.com • Are they real? Will they be? • Some people think so • Won’t they be routed direct? (rfc3263) • Maybe, maybe not

  6. 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

  7. 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

  8. 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

More Related