Luf vs lrf
Download
1 / 12

LUF vs. LRF - PowerPoint PPT Presentation


  • 154 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'LUF vs. LRF' - ros


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Luf vs lrf

LUF vs. LRF

draft-schumacher-drinks-luf-lrf-diff-01.txt

Greg Schumacher, Hadriel Kaplan


What s an luf
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
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
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
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
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
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
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
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
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
Example 2: Real world

SSP-C

SSP-A

SSP-B

SSP-E

SSP-F


ad