120 likes | 347 Views
LUF vs. LRF. draft-schumacher-drinks-luf-lrf-diff-01.txt Greg Schumacher, Hadriel Kaplan. What’s an LUF?. From Speermint-Terminology: “The Look-Up Function (LUF) provides a mechanism for determining for a given request the target domain to which the request should be routed.”
E N D
LUF vs. LRF draft-schumacher-drinks-luf-lrf-diff-01.txt Greg Schumacher, Hadriel Kaplan
What’s an LUF? • From Speermint-Terminology: “The Look-Up Function (LUF) provides a mechanism for determining for a given request the target domain to which the request should be routed.” • The question is: what does “target domain” mean? • Option A: terminating domain • Option B: next-domain Of course sometimes they are the same domain • Option C: next-hop/next-trunk? Note: this isn’t a question about what a specific box does – it can do LUF and LRF in one transaction
Proposal • Change terminology to define LUF as: “The Look-Up Function (LUF) provides a mechanism for determining for a given request the target terminating domain to which the request should be routed.” • Change terminology to define LRF as: “The Location Routing Function (LRF) determines for the target terminating domain of a given request the location of the SF in that domain and optionally develops other SED required to route the request to that domain, possibly through transit SSPs.“
Example 1: Bilateral peer 1: Where is +1234567890? 2: <sip:+1234567890@b.com> 3: INVITE sip:+1234567890@b.com LUF 1 2 3 SSP-A SSP-B
Example 1: The real world Even bi-lateral peering in the real world is not one trunk, not all trunks are created equal, and it often depends on where the request came from SSP-A SSP-B
Why LUF answer is not next-hop • SF addressing is not static - they change due to dynamic, temporary topology changes, or operator control • SF address availability/reachability is not global • SF addresses overlap - some SSP's use RFC-1918 addresses • SF addresses are private - many SSPs do not wish to publish the SBE addresses they use for all peering connections with all peers
Example 2: Transit peering LUF 1: Where is +1234567890? 2: <sip:+1234567890@b.com> 3: INVITE sip:+1234567890@b.com 1 2 SSP-C SSP-A SSP-B SSP-E SSP-F 3 How do I get to b.com?
Why LUF is not next-domain • Transit SSP connections are not static • Transit SSP connections are not globally routable - some SSP peering connections only service direct bi-lateral traffic, while others are usable for transit traffic but only for specific regions or national codes • Transit SSP connection details are private • Loops can happen – the LUF in subsequent domains does not know the routing history of the request
So what is LRF? 1: Where is +1234567890? 2: <sip:+1234567890@b.com> 3: INVITE sip:+1234567890@b.com • LRF determines how to reach b.com • Currently through static provisioning (retrieved on-box or through ENUM/SIP-redir queries) • Resulting SIP request example: INVITE sip:+1234567890@b.com SIP/2.0Route: <sip:sbe1.e.com;lr> • Or another, in request-uri:sip:+1234567890;tgrp=trunk1.e.com;trunk-context=a.com@b.com
Why split them out? • LUF can be easily centralized, should be centralized • LRF may be centralized, distributed, or both • LUF rules/decisions/answers are not typically different based on who’s asking • LRF almost always is different for that • LUF security/privacy properties are very different from LRF
Example 2: Real world SSP-C SSP-A SSP-B SSP-E SSP-F