Subject: [Speermint] More comments on draft-ietf-speermint-terminology

From: Otmar Lendl <[email-masked]>
Date: Fri, 11 Aug 2006 23:49:51 +0200

On 2006/08/11 20:08, David Meyer <[email-masked]> wrote:
> 
> 	I've updated with your comments (and a few others). -03

Meanwhile, I've had a closer look at -02, here are my comments:

------------------
>
>3.  General Definitions
>
>3.1.  Call Routing Data
>
>   Call Routing Data, or CRD, is a SIP URI used to route a call (real-
>   time, voice or other type) to the called domain's ingress point.  A
>   domain's ingress point can be thought of as the location pointed to
>   by the SRV record that resulted from the resolution of the CRD (i.e.,
>   a SIP URI).

I don't consider this definition to be intuitive. I'd prefer to use
Call Routing Data to be the output of the Speermint Routing algorithm.
In my mind, that should be

	* Destination SIP URI (most likely to be identical to the input)
	* SIP proxy to send the INVITE to
		- FQDN
		- Port
		- Transport Protocol (udp/tcp/tls)
	* Security Parameters
		- TLS cert to use
		- TLS cert to expect
		- TLS cert verification setting
	* Congestion Control parameters
		- Static settings
		- Which dynamic protocol to use

Eventually, the CRD could even be a priorized list of such parameters which
defines a number of alternative routes.

As I see it, the CRD is the set of parameters the outgoing border
elements needs to complete the call.

I'd use "Call Addressing Data" for your definition of CRD.

>3.2.  Call Routing
>
>   Call routing is the set of processes, rules, and CRD used to route a
>   call to its proper (SIP) destination.  More generally, call routing
>   can be thought of as the set of processes, rules and CRD which are
>   used to route a real-time session to its termination (ingress) point.

I see the CRD as the output of the call routing process.

>3.4.  Network
>
>   For purposes of this document and the SPEERMINT and ENUM Working
>   Groups, a network is defined to be the set of SIP servers and end-
>   users (customers) that are controlled by a single administrative
>   domain and can be reached via layer 3 (IP) peering.  The network may
>   also contain end-users who are located on the PSTN, as long as they
>   are also reachable via layer 3 (IP) peering.

I don't understand this definition. SIP servers are layer 5 devices,
but the rest of this definition talks about layer 3 issues.

This definition certainly applies to an integrated Layer3 + Layer5 provider
(e.g. a cable isp which supplies VoIP services to its customers), but
I have troubles understanding if this definition applies to the 
Vonage case where the SIP layer is independent of the IP layer.

If this definitions is supposed to differentiate between these who cases 
I suggest we use a clearer term like "integrated L3/L5 network" or
"vertical silo network".

>3.5.  Service Provider (SP)
>
>   A Service Provider (or SP) is defined to be an entity that controls a
>   "network" as defined in Section 3.4, and provides transport of SIP
>   signaling and media packets.

If the intention here is use SP for providers of both L3 and L5 services,
then I suggest we use something like an "Integrated SP" for this
special case.

>3.6.  Voice Service Provider (VSP)
>
>   A Voice Service Provider (or VSP) is an entity that provides
>   transport of SIP signaling (and possibly media streams) to its
>   customers.  Such a service provider may additionally be
>   interconnected with other service providers; that is, it may "peer"
>   with other service providers.  A VSP may also interconnect with the
>   PSTN.
>
>   Note that as soon as a ingress point is advertised via a SRV record,
>   anyone can find that ingress point and hence can send calls there.
>   This is very similar to sending mail to a SMTP server based on the
>   existence of a MX record.
>
>   Finally, note the concept of a VSP is a subset of the possible SP
>   types.  That is, a VSP is an SP, but it is not necessary that an SP
>   be a VSP.

I think we're mixing a few issues here in our taxonomy of service
providers. Let's take a step back and look at the properties we can
use to classify service providers:

* Which service is provided? Layer 3 or Layer 5?

* L3 / L5 integration

	See the comment on "network" above.

* Callable by RFC 3261/3263 procedures on the public Internet

	The existence of SRV records does IMHO not imply that the
	SIP server to which these records point to will accept any
	call from the Internet.	

(the latter two are orthogonal properties)

As the term Service Provider (SP) doesn't indicate whether we're
talking about Layer3 or Layer5 services, I propose that we use

ISP: the SP which provides Layer 3 services (IP connectivity)
VSP: the SP which provides Layer 5 services (SIP service)

That leaves us to define terms to distinguish between L3/L5 integrated
SP vs. L5 only VSPs and open vs. closed ones.

What about "IVSP" for L3/L5 Integrated VoIP Service Provider?
We could then call VSPs which are not IVSPs (the vonage model) "nIVSP"
for non-integrated VSP.

Regarding reachability via the Internet, I propose to use 
"open VSPs" versus "closed VSPs".

>4.3.  Direct Peering
>
>   Direct peering describes those cases in which two domains
>   interconnect without using an intervening layer 5 network.  Both
>   domains must have a trust relationship established (for example, they
>   may know they belong to the same federation; see Section 6 below)
>   before opening up a secure layer 5 communication path.
>
>4.4.  Indirect (Transit) Peering
>
>   Indirect (transit) peering refers to the establishment of a secure
>   signaling path via one (or more) referral or transit network(s).  In
>   this case it is required that a trust relationship is established
>   between the originating domain and the transit network on one side,
>   and the transit network and the termination network on the other
>   side.  Both trust relationships must exist before opening up a secure
>   communication path on L5.

There may be a third way of peering, let's call it "Assisted Peering".
That would be the XConnect model where a federation employs a
central SIP proxy (which is in itself not a VSP) to bridge calls
between participating networks. That's a bit like the BGP route-reflectors
employed at various L3 Internet Exchanges, which are present in
the L3 routing protocol, but not in the actual L3 packet routing.

Regarding trust: I wouldn't say that trust "must exist before opening
up a secure communication path" as trust could be established during
this opening phase, e.g. through the use of TLS certs.

>5.  ENUM
>5.2.  User ENUM

We might add here that User ENUM implies that the URIs published
therein refer to open VSPs.

>5.3.  Infrastructure ENUM
>
>   In infrastructure ENUM, only the COR may enter data in the
>   corresponding domain.  The COR may also enter CRD (i.e., a SIP URI)
>   to allow other SPs to to route sessions to its network.

I'd note here that this SIP URI does not need to be hosted at an open VSP.

>6.  Federations
>
>   The domain policy DDDS application [I-D.lendl-domain-policy-ddds]
>   defines a method with which a domain owner can announce the policy it
>   will use to accept incoming calls.  This section introduces a policy
>   type for use with that framework, known as federations
>   [I-D.lendl-speermint-federations].
>
>   Note that [I-D.lendl-domain-policy-ddds] does not define what these

That should be [I-D.lendl-speermint-federations]
 
>   rules can be or how they might be communicated to the members of a
>   federation.  Further, there is no requirement that such rules are in
>   any way public.
>
>6.1.  Federation Functionality
>
>   A federation may provide some or all of the following functionality:
>
>      *  Common policies
>
>         +  Policy might be ah-hoc, and published in the DNS (e.g.,
>            [I-D.lendl-domain-policy-ddds], or

I'll submit another I-D soon which will discuss this in more detail
than the examples section of the DP-DDDS draft. 

>         +  Policy might also be managed by a federation entity

In which case the DNS just refers to a named policy.

>      *  A federated ENUM root
>
>      *  Address resolution mechanisms
>
>      *  Session signaling (via federation policy)
>
>      *  Media streams (via federation policy)
>
>      *  Federation security policies
>
>      *  Interconnection policies
>
>      *  Other layer 2 and layer 3 policies
>
>   Finally, note that a SP can be a member of
>
>      *  No federation (e.g., the SP has only bilateral peering
>         agreements)
>
>      *  A single federation
>
>      *  Multiple federations
>
>   and an SP can have any combination of bi-lateral and multi-lateral
>   (i.e., federated) interconnections.

One could argue that bi-lateral peerings are just special cases of
federations (i.e. a federation with two members).

>6.2.  Announcement of Federation Membership
>
>   Announcement of federation membership is typically made by the
>   terminating SP, using one or more of the following mechanisms:
>
>      *  I-ENUM

What do you have in mind here? Richard Stastny's Enum resolution Context
draft?

>      *  A Private ENUM Federation discovery mechanism
>
>      *  DNS
>
>6.3.  Example Federation Rules
>
>   Example federation rules might include the following:
>
>   o  A set of SPs form an association and agree to accept calls from
>      each other via the public Internet as long as the SIP call uses
>      TCP/TLS as transport protocol and presents a X.509 cert which was
>      signed by the association's own CA.
>
>   o  A set of SPs build a L3 network dedicated to VoIP peering (e.g.,
>      the 3GPP GRX).  The further agree to accept calls from all
>      participants in that network and bill each other via a
>      clearinghouse.
>
>   o  A set of SPs agree to accept calls originating from within the
>      same country.  They use a set of firewall rules to block calls
>      from abroad.

This example seems to have confused many people. I've replaced it in
my latest draft by

   o  A group of VoIP service providers agree to accept calls
      originating from each other.  They use firewall rules to
      block calls from all other networks.

-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

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

---

From: David Meyer <[email-masked]>
Date: Mon, 14 Aug 2006 07:13:53 -0700

Thanks, will update accordingly.

	--dmm

---

From: David Meyer <[email-masked]>
Date: Tue, 15 Aug 2006 09:24:04 -0700

OK, see

	 http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt

> I'd use "Call Addressing Data" for your definition of CRD.
  
	I have so far resisted this.

> "open VSPs" versus "closed VSPs".

	I've also (so far) resisted all of this terminology.
	My sense is that this is way too complicated for what we
	want to achieve.

	I'd be interested in what the WG thinks...

	--dmm

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 15 Aug 2006 22:06:47 +0200

> 	My sense is that this is way too complicated for what we

We could well do without that. I didn't quite grasp what you tried
to express with the definitions of VSP vs. SP in -02. That's why
I tried to clarify and describe how I'd categorize service providers.

/ol