Subject: FW: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology

From: "David Schwartz" <[email-masked]>
Date: Mon, 9 Jul 2007 13:10:54 +0300

Hi Daryl

I know it's probably too late for this to make it in but I just have a
few comments. You define "Assisted Peering" as employing a central SIP
proxy - therefore forcing a hub-and-spoke model for this category. I see
it differently. I see assisted as "assisting" in call setup but not
necessarily having to be in the actual call path. 

As discussed in previous emails on this thread "Assisted" should be
orthogonal to both direct and indirect and if indeed a centralized SIP
proxy is deployed than this is an instantiation of both assisted and
indirect peering.

I would word 4.2.1 - 4.2.3 as follows...

4.2.1. Direct Peering 

   Direct peering describes those cases in which two service providers 
   interconnect without using an intervening layer 5 network. 

4.2.2. Indirect Peering 

   Indirect, or transit, peering refers to the establishment of a either
   a signaling and media path or signaling path alone via one (or more)

   referral or transit network(s). Transit network may be used for
technical     
   reasons (e.g. signaling interoperability or media transcoding) or non

   technical reasons (e.g. QoS, Anonymity). It is generally required
that 
   a trust relationship is established between the originating service 
   provider and the transit network on one side, and the transit network

   and the termination network on the other side. 

4.2.3. Assisted Peering 

   In this case, some entity (usually a federation, see Section 5) 
   provides peering assistance to either the originating or terminating 
   party. Examples of such assistance can include (but are not limited
to):

   * The lookup function (who owns the number)
     
     * covers any mechanism reducing the need for an endpoint 
       to hold all number ranges of all his peers (this can 
       include a centralized database accessible via ENUM or a 
       DHT containing relevant lookup information)

   * The policy function (who can see what and how)

       * Who gets a direct uri to other peer 
       * Who must use intermediary
       * Who gets a 404 Not found

   * The location function (ingress point at terminating or transit
peer)
     
     * covers any mechanism (including BUT NOT LIMITED to RFC 3263) used
       to locate the next routing hop for this call. Note that this may 
	 require the assistance of an element filling the role of
indirect 
       peering as described above. Note as well that this may or may not
       be related to lookup function.

If we can agree on these definitions than there is no need for the
additional definitions of on-demand and static peering as these can be
represented in terms of the 3 defined terms. For example, on-demand
peering is defined today as follows...

   Service providers are said to peer on-demand when they are able to 
   exchange traffic without any pre-association prior to the origination

   of a real-time transaction (like a SIP message) between the domains. 
   Any information that needs to be exchanged between domains in support

   of peering can be learned through a dynamic protocol mechanism.  On-
   demand peering can occur as direct, indirect, or assisted. 

What is described here can be implemented with a public ENUM root
coupled with RFC 3263 filling the roles of Assisted peering and the
signaling going directly to the terminating peer filling the role of
Direct peering. So why introduce another confusing term?

If we think of the 3 peering terms in a logical as opposed to physical
sense all models can fold into these terms.

One final note. As you probably noticed under assisted peering I broke
the location function into a lookup function and a location function. In
my experience it is this subtlety that can provide most of the
flexibility we need to accommodate most of the models out there. While
in many or most cases one URI can be used both for lookup and location -
the flexibility to have separate URIs for these must not be sacrificed.
I would therefore add this term to the draft as well.

Once again I am so sorry that these comments are coming so late but my
circumstances did not allow me to devote any time to this until now :(

Your thoughts?

D.

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Saturday, July 07, 2007 1:30 AM
To: [email-masked]
Subject: [Speermint] Terminology Draft vs. VoIP Usecases Draft
Terminology

Adam et. al. (Authors of
"draft-ietf-speermint-voip-consolidated-usecases"),

Okay, I read through the terminology of the "voip-consolidated-usecases"
draft, and here is my analysis:
 
Remove the following term definitions from your draft, because they
are already covered in the terminology draft:
 
Direct Peering
Indirect Peering
Assisted Peering
Federations (Note...you have Federations in your terminology section
twice!)
Voice Service Provider (Now SSP in Terminology draft)
Signaling Border Element
Data Path Border Element
Peering Service Provider - The function of this is included in the SIP
Service Provider definition.
Direct PSP - I think this is also covered by existing definitions
Assisting PSP - Same as Direct PSP comment.
 
There are 3 (1 definite, 2 questionable) terms, which should be added to
the next rev. of the terminology draft:
 
Location Server
Session Manager - Although I'm not quite sure I understand exactly
what this does.
User Endpoint - Again, I'm not sure what this is, because this should
be a UAC, UAS, or UA in my opinion.  These are well defined in RFC 3261
and referenced in the terminology draft.
 
Other terms, which I think should remain in your draft and NOT in the
terminology draft are more specific delineations of the terms in the
terminology draft.  They include:
 
Originating VSP - Which at a minimum should be changed to Originating
SSP to remain consistent with the terminology draft.
Terminating VSP - See Originating VSP comment.
O-SBE
T-SBE
t-SBE
A-SBE
O-DBE
T-DBE
t-DBE
 
This my two cents...Thoughts...--Daryl

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

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

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 9 Jul 2007 12:31:31 +0200

Hi,
 
I basically agree with David
 
I have only two comments:
 
1. In the definitions 4.2.1 - 4.2.3 the term "network" is used.
First, this term is not defined anywhere and secondly, it is IMO wrongly
used on Layer 5.
 
In the definitions of section 3 the term "domain" is used, it should also be used
here, or even better "administrative domain"
 
2. I like the separation David proposes with the lookup function
and the location function. It should also be stated clearly
that we mean with location function the locating of SIP servers
and not the locating of the end-user.
 
Richard

________________________________

Von: David Schwartz [mailto:[email-masked]]
Gesendet: Mo 09.07.2007 12:10
An: Malas, Daryl
Cc: [email-masked]
Betreff: FW: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology

Hi Daryl

4.2.1. Direct Peering

4.2.2. Indirect Peering

4.2.3. Assisted Peering

    

    

Your thoughts?

D.

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]]
Sent: Saturday, July 07, 2007 1:30 AM
To: [email-masked]
Subject: [Speermint] Terminology Draft vs. VoIP Usecases Draft
Terminology

Adam et. al. (Authors of

Direct Peering
Indirect Peering
Assisted Peering

Location Server

---

From: Daryl Malas <[email-masked]>
Date: Tue, 10 Jul 2007 10:44:05 -0600

Re: 4.2.2 - I updated the section, it now reads:
Indirect, or transit, peering refers to the establishment of either a
signaling and media path or signaling path alone via one (or more)
referral or transit network(s). In this case it is generally required
that a trust relationship is established between the originating service
provider and the transit network on one side, and the transit network
and the termination network on the other side.

--I left out the portion you have describing what a Transit network may
be used for, since I think this should be included in the "use case"
draft.

Re: 4.2.3 - I updated the section, it now reads:
In this case, some entity (usually a federation, see Section 5) provides
peering assistance to either the originating or terminating peer by
providing one or more functions (see Section 4.3) on behalf of the peers
(which is not itself a SSP) to bridge calls between participating
networks.

I've now included a section of the terminology draft to include the
functions as defined in the "architecture" draft.  These functions
include Location, Signaling, and Media.  In the architecture draft, I
think it should be described within the Location function the ability to
do a "Lookup" as a sub-function.  This is a similar to what I encouraged
for describe sub-terms within the use case draft.  Finally, the "Policy"
function has been argued again and again, and this has been
intentionally removed at this point from all of the drafts.  Per the WG
chairs, this can be defined in a separate draft as necessary in the
future.

Thanks...I will submit -09, but I may need to post it to a website if
they will not accept it (due to beyond the deadline).

--Daryl

---

From: Daryl Malas <[email-masked]>
Date: Tue, 10 Jul 2007 10:51:03 -0600

I clarified the Location Function definition to make sure it does not
indicate it provides the location of the end-user, but rather the SF of
the SSP.

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 11 Jul 2007 12:32:55 +0200

David,

On 2007/07/09 12:07, David Schwartz <[email-masked]> wrote:
>    party. Examples of such assistance can include (but are not limited to):
> 
>    * The location function (ingress point at terminating or transit peer)
>      
> 	 require the assistance of an element filling the role of indirect 

I really like way you structured the peering problem into these three steps.

Limiting this to "Assisted Peering" is selling the idea short, though:
Even direct and indirect peering have to perform these three steps
(although they might be mixed up in some cases).

Let's look how standard ENUM/SIP performs these three steps:

 * The lookup function (who owns the number)
 	User ENUM according to RFC3761. Public DNS.
 * The policy function (who can see what and how)
	Not needed as everybody talks to everybody
 * The location function (ingress point at terminating or transit peer)
	RFC 3263: NAPTR/SRV/A lookup

My proposal from last year (see
http://tools.ietf.org/html/draft-lendl-domain-policy-ddds-02 and
http://tools.ietf.org/html/draft-lendl-speermint-federations-03 ) 
can also be described according to this scheme:

 * The lookup function (who owns the number)
 	Public Infrastructure ENUM 
 * The policy function (who can see what and how)
	It's not a question of "can see", but "can use":
	Domain policy DDDS application (see the drafts)
 * The location function (ingress point at terminating or transit peer)
	Federation specific.

> I would therefore add this term to the draft as well.

Once again, I concur.

The flexibility gained by this approach makes a simple, unified
peering architecture for all scenarios feasible.

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /