Subject: [Speermint] Lookup Function and Location Function

From: Daryl Malas <[email-masked]>
Date: Mon, 23 Jul 2007 14:07:14 -0600

The question came up today as to whether or not the Location Function
term should be broken into Look-up and Location Function.  Below is the
"Location Function" as it is defined today, and the proposed "Look-up
Function".  Another way to look at it...should a "Look-up Function" be
defined in addition to the "Location Function".  

Location Function -

The Location Function (LF) develops call routing data (CRD) by
discovering the Signaling Function (SF), and SF's reachable host (IP
Address and port).

Look-up Function -

The Look-up Function provides a mechanism for querying an internal
and/or external database, which maintains a list of SIP user names and
associated peering domains.

Thanks...--Daryl

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "David Schwartz" <[email-masked]>
Date: Mon, 23 Jul 2007 23:31:56 +0300

I am ok with that.

Thanks

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 11:07 PM
To: [email-masked]
Subject: [Speermint] Lookup Function and Location Function

Location Function -

Look-up Function -

Thanks...--Daryl

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 23 Jul 2007 17:57:49 -0400

I think this distinction is necessary. When I was updating the arch
draft I was struggling on how to map SM and LS (as defines by use
cases-02) to LF.

I think today SM is contained within both LF and LUF (Look-up function).
In the use cases draft it says SM is logical and can contain more than
one entity. The problem is that LF and LUF are also logical. Usually
architectures are defined cased on functions/logical entities.

We need to define the top of the hierarchy. IMHO should start with LF,
MF, SF and map everything (elements/boxes) to it. Today seems the other
way around, we are defining elements (SBE, etc) and putting functions on
them. But the function can span more than one element, so things start
to get complicated. 

> Sent: Monday, July 23, 2007 1:07 PM
> To: [email-masked]
> The question came up today as to whether or not the Location 
> Function term should be broken into Look-up and Location 
> Function.  Below is the "Location Function" as it is defined 
> today, and the proposed "Look-up Function".  Another way to 
> look at it...should a "Look-up Function" be defined in 
> addition to the "Location Function".  
> 
> Location Function -
> 
> The Location Function (LF) develops call routing data (CRD) 
> by discovering the Signaling Function (SF), and SF's 
> reachable host (IP Address and port).
> 
> Look-up Function -
> 
> The Look-up Function provides a mechanism for querying an 
> internal and/or external database, which maintains a list of 
> SIP user names and associated peering domains.
> 
> Thanks...--Daryl
> 
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 23 Jul 2007 21:01:19 -0400

Both LF and LUF are providing services to find the next-hop. In the use
case draft, the LF is the entity that contains both LF and LUF. SM is
the signaling entity that connects the UAC and UAS. SM doesn't contain
any user-to-location mapping. It sends the LF request to the LF.

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 5:58 PM
To: Daryl Malas; [email-masked]
Subject: RE: [Speermint] Lookup Function and Location Function

> term should be broken into Look-up and Location Function.  Below is 
> the "Location Function" as it is defined today, and the proposed 
> "Look-up Function".  Another way to look at it...should a "Look-up 
> Function" be defined in addition to the "Location Function".
> 
> Location Function -
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 24 Jul 2007 00:07:19 -0400

Hello Yiu,

The word "LF" does not even appear in the user cases draft.  

On the other hand, the definition of SM says:

"It is also responsible for locating the user home 
           proxy. SM is logical, it MAY contain one functional entity or

           multiple functional entities.  "

Special attention to "...locating the user home proxy..".

So, putting these two together we do not have a clear picture of LF,
LUF, SM and others.

My suggestion is the use cases draft put SBE, DBE, and others in the
context of LF, SF, and MF.

In other words, how these boxes map to the functions in the arch draft.

Thanks,

Reinaldo

> From: Lee, Yiu [mailto:[email-masked]] 
> Sent: Monday, July 23, 2007 6:01 PM
> To: Reinaldo Penno; Daryl Malas; [email-masked]
> Both LF and LUF are providing services to find the next-hop. 
> In the use case draft, the LF is the entity that contains 
> both LF and LUF. SM is the signaling entity that connects the 
> UAC and UAS. SM doesn't contain any user-to-location mapping. 
> It sends the LF request to the LF.
> 
> 
> I think this distinction is necessary. When I was updating 
> the arch draft I was struggling on how to map SM and LS (as 
> defines by use
> cases-02) to LF.
> 
> In the use cases draft it says SM is logical and can contain 
> more than one entity. The problem is that LF and LUF are also 
> logical. Usually architectures are defined cased on 
> functions/logical entities.
> 
> We need to define the top of the hierarchy. IMHO should start 
> with LF, MF, SF and map everything (elements/boxes) to it. 
> Today seems the other way around, we are defining elements 
> (SBE, etc) and putting functions on them. But the function 
> can span more than one element, so things start to get complicated. 
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 24 Jul 2007 11:15:27 -0400

Ah, I see where the confusion comes from  :-) In the -03 draft, SM is:

Session Manager (SM): A SM is the home registrar of the user 
           endpoint. SM is responsible to receive and send SIP messages
from 
           the peer. If the user endpoint speaks non-SIP, SM will
translate 
           the non-SIP protocol to SIP protocol and vice versa. 

We don't have LF defined in the draft because we referenced the LF from
the term draft. Since the term draft is updated to show LF and LUF, we
will update the use-case draft accordingly.

Thanks,
Yiu 

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 12:07 AM
To: Lee, Yiu; Daryl Malas; [email-masked]
Subject: RE: [Speermint] Lookup Function and Location Function

Hello Yiu,

Thanks,

Reinaldo

> In the use case draft, the LF is the entity that contains both LF and 
> LUF. SM is the signaling entity that connects the UAC and UAS. SM 
> doesn't contain any user-to-location mapping.

> MF, SF and map everything (elements/boxes) to it.
> Today seems the other way around, we are defining elements (SBE, etc) 
> and putting functions on them. But the function can span more than one

> element, so things start to get complicated.
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 24 Jul 2007 15:32:24 -0400

Yiu - If you are proposing a modification to the suggested text, please
submit that in full in this thread.  

Thanks
Jason 

> From: Lee, Yiu [mailto:[email-masked]] 
> Sent: Monday, July 23, 2007 9:01 PM