Subject: [drinks] What do we mean by "peering"?

From: Dean Willis <[email-masked]>
Date: Wed, 4 Apr 2012 20:57:04 -0500

Peering seems to be a very loaded term. When David explains it to me, it seems it means to him a whole lot of business-specific rules related to the routes along which calls can be made. It includes things like time-of-day, pricing, periodic contractual commitments with different rates, available bandwidth, available QoS, SLAs and all those myriad things that make up the black magic of the "policy server".

We have a much simpler view of "peering" in the framework document. Here, we merely concerned with the sharing of routes. We have a route, we offer it to someone, and if they accept the route, it will appear when they appropriately query the engine that access our data (although how said database determines query-identity/authority using the information in the database seems to be perplexingly out of scope).

But in short, what we're really talking about is a sort of per-route access-control list that has two facets: the "Is allowed to see this route" facet, and the dependent "wants to see this route in its responses" facet. As far as I can tell, we don't even have a way to retract permission once granted; the only option is to to retract a route accepted by example.com is to delete the route, then re-offer it to everybody on the old list except example. com, then wait for them to accept the "new" route. Personally this seems like a clusterpluck, but it's what we agreed to.

While we could certainly quibble forever on cleaning up this semantics in the protocol (and end up with the "Session Establishment Data Sharing Protocol), it's been proposed that we don't need to, and that all we need to do is to explain this concept of "peering by sharing routes" succinctly within the draft.

Let me try by re-writing the introduction:

1.  Introduction

Service providers and enterprises use registries to make session routing decisions for Voice over IP, SMS and MMS traffic exchanges. This document is narrowly focused on the provisioning framework for these registries.  In other words, the goal is to allow users to put session establishment data (SED) into a registry, to share that SED selectively with other users of that registry, and to allow those other users to further select a subset of that SED for use in their own applications.  The requirements and use cases driving this framework have been documented in [RFC6461 ], and the reader is expected to be familiar with the terminology defined therein.

The SED described in this framework is limited to simple routing data. Although the terms "peer" and "peering" are used, these refer only to the sharing of basic call routing information between users of the registry, and do not address the broad range of policy factors that might be used in a commercial peering "clearinghouse" operation. In short "peering organizations" are other users of the same registry, and "peers" are users of that registry to whom the offer of sharing specific SED has been extended, and who have accepted that offer.

Three types of data flows are described in [RFC 6471]: client to/from registry, registry to local data repository and registry to registry, as shown here:

    *--------*               *------------*               *------------*
    |        | (1). Client   |            | (3).Registry  |            |
    | Client | <-----------> |  Registry  |<------------->|  Registry  |
    |        |   to Registry |            |  to Registry  |            |
    *--------*               *------------*               *------------*
                                  /  \                          \
                                 /    \                          \
                                /      \                          \
                               /        \                          v
                              /          \                         ...
                             /            \
                            / (2). Distrib \
                           / Registry data  \
                          /  to local data   \
                         V      store         V
                        +----------+       +----------+
                        |Local Data|       |Local Data|
                        |Repository|       |Repository|
                        +----------+       +----------+

                     Three Registry Provisioning Flows

This document addresses only the (1) Client to Registry aspect.  This document defines an abstract framework for the interaction of registry clients with registries, referred to as the Session Peering Provisioning Framework (SPPF).  This abstract framework is to be mapped into specific protocol bindings in other documents, initially to SOAP in [draft-ietf-drinks-spp-soap].

The data provisioned for session establishment is typically used by various downstream SIP signaling systems to route a call to the next hop associated with the called domain.  These systems typically use a local data store ("Local Data Repository") as their source of session routing information.  More specifically, the SED data is the set of parameters that the outgoing signaling path border elements (SBEs) need to initiate the session.  See [RFC5486] for more details.

A "terminating" SIP Service Provider (SSP) provisions SED into the registry to be selectively shared with other SSPs. Subsequently, a registry may distribute the provisioned data into local data repositories used for look-up queries (identifier -> URI) or for lookup and location resolution (identifier -> URI -> ingress SBE of terminating SSP).  In some cases, the registry may additionally offer a central query resolution service (not shown in the above figure). Typically, this query resolution service will be something like an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server.

The roles of  "client" and "server" are abstract and only apply to the requesting and responding roles in given transactions and are not related in any way to the type of entity participating in a protocol exchange.  For example, a registry might also include a "client" when such a registry initiates a connection (for example, for data distribution to an SSP).

... continue with existing text from "A key requirement..."

---

From: David Schwartz <[email-masked]>
Date: Thu, 5 Apr 2012 11:29:47 +0300

Hi Dean

I am ok with your proposal. Here is a slight modification of the second paragraph...

The SED described in this framework is limited to simple routing *** and targeting *** data. Although the terms "peer" and "peering" are used, these refer only to the sharing of basic call routing *** and targeting *** information between users of the registry, and do not address the broad range of policy factors that might be used in a commercial peering "clearinghouse" operation. In short "peering organizations" are other users of the same registry, and "peers" are users of that registry to whom the offer of sharing specific SED has been extended, and who have accepted that offer.

:D

On Apr 5, 2012, at 4:57 AM, Dean Willis wrote:

But in short, what we're really talking about is a sort of per-route access-control list that has two facets: the "Is allowed to see this route" facet, and the dependent "wants to see this route in its responses" facet. As far as I can tell, we don't even have a way to retract permission once granted; the only option is to to retract a route accepted by example.com<http://example.com/> is to delete the route, then re-offer it to everybody on the old list except example. com, then wait for them to accept the "new" route. Personally this seems like a clusterpluck, but it's what we agreed to.

1.  Introduction

<ATT00001..c>

---

From: Dean Willis <[email-masked]>
Date: Tue, 10 Apr 2012 11:55:29 -0500

I'm finding that "target" has been heavily overloaded; we have the OMA
version, the 3GPP version, Christer's version, old SIP text, and so on.

So I'm confused.

What is the difference between routing and targeting (and retargeting) in
your world view?

On Thu, Apr 5, 2012 at 3:29 AM, David Schwartz <[email-masked]>wrote:

> The SED described in this framework is limited to simple routing *** and
> targeting *** data. Although the terms "peer" and "peering" are used, these
> refer only to the sharing of basic call routing *** and targeting ***
> information between users of the registry, and do not address the broad
> range of policy factors that might be used in a commercial peering
> "clearinghouse" operation. In short "peering organizations" are other users
> of the same registry, and "peers" are users of that registry to whom the
> offer of sharing specific SED has been extended, and who have accepted that
> offer.
>
> :D
>
>
> Peering seems to be a very loaded term. When David explains it to me, it
> seems it means to him a whole lot of business-specific rules related to the
> routes along which calls can be made. It includes things like time-of-day,
> pricing, periodic contractual commitments with different rates, available
> bandwidth, available QoS, SLAs and all those myriad things that make up the
> black magic of the "policy server".
>
>
> We have a much simpler view of "peering" in the framework document. Here,
> we merely concerned with the sharing of routes. We have a route, we offer
> it to someone, and if they accept the route, it will appear when they
> appropriately query the engine that access our data (although how said
> database determines query-identity/authority using the information in the
> database seems to be perplexingly out of scope).
>
> But in short, what we're really talking about is a sort of per-route
> access-control list that has two facets: the "Is allowed to see this route"
> facet, and the dependent "wants to see this route in its responses" facet.
> As far as I can tell, we don't even have a way to retract permission once
> granted; the only option is to to retract a route accepted by example.comis to delete the route, then re-offer it to everybody on the old list
> except example. com, then wait for them to accept the "new" route.
> Personally this seems like a clusterpluck, but it's what we agreed to.
>
>
> While we could certainly quibble forever on cleaning up this semantics in
> the protocol (and end up with the "Session Establishment Data Sharing
> Protocol), it's been proposed that we don't need to, and that all we need
> to do is to explain this concept of "peering by sharing routes" succinctly
> within the draft.
>
>
> Service providers and enterprises use registries to make session routing
> decisions for Voice over IP, SMS and MMS traffic exchanges. This document
> is narrowly focused on the provisioning framework for these registries.  In
> other words, the goal is to allow users to put session establishment data
> (SED) into a registry, to share that SED selectively with other users of
> that registry, and to allow those other users to further select a subset of
> that SED for use in their own applications.  The requirements and use cases
> driving this framework have been documented in [RFC6461 ], and the reader
> is expected to be familiar with the terminology defined therein.
>
> The SED described in this framework is limited to simple routing data.
> Although the terms "peer" and "peering" are used, these refer only to the
> sharing of basic call routing information between users of the registry,
> and do not address the broad range of policy factors that might be used in
> a commercial peering "clearinghouse" operation. In short "peering
> organizations" are other users of the same registry, and "peers" are users
> of that registry to whom the offer of sharing specific SED has been
> extended, and who have accepted that offer.
>
> Three types of data flows are described in [RFC 6471]: client to/from
> registry, registry to local data repository and registry to registry, as
> shown here:
>
>
>
> This document addresses only the (1) Client to Registry aspect.  This
> document defines an abstract framework for the interaction of registry
> clients with registries, referred to as the Session Peering Provisioning
> Framework (SPPF).  This abstract framework is to be mapped into specific
> protocol bindings in other documents, initially to SOAP in
> [draft-ietf-drinks-spp-soap].
>
> The data provisioned for session establishment is typically used
> by various downstream SIP signaling systems to route a call to the next hop
> associated with the called domain.  These systems typically use a local
> data store ("Local Data Repository") as their source of session routing
> information.  More specifically, the SED data is the set of parameters that
> the outgoing signaling path border elements (SBEs) need to initiate the
> session.  See [RFC5486] for more details.
>
> A "terminating" SIP Service Provider (SSP) provisions SED into
> the registry to be selectively shared with other SSPs. Subsequently, a
> registry may distribute the provisioned data into local data repositories
> used for look-up queries (identifier -> URI) or for lookup and location
> resolution (identifier -> URI -> ingress SBE of terminating SSP).  In some
> cases, the registry may additionally offer a central query resolution
> service (not shown in the above figure). Typically, this query resolution
> service will be something like an ENUM [RFC 3761] server or a SIP [RFC
> 3261] proxy or redirect server.
>
> The roles of  "client" and "server" are abstract and only apply to the
> requesting and responding roles in given transactions and are not related
> in any way to the type of entity participating in a protocol exchange.  For
> example, a registry might also include a "client" when such a registry
> initiates a connection (for example, for data distribution to an SSP).
>

---

From: David Schwartz <[email-masked]>
Date: Tue, 10 Apr 2012 22:24:18 +0300

To be honest I never liked the term "target" but it was the only one we could agree on. To me, the target is basically the NON-ROUTABLE name or identity of the party or entity claiming ownership (i.e. can terminate a call to) of an e.164 identifier - WHO not WHERE. The sticky part was dealing with the whole transit issue, and the use of "target" was an attempt to disambiguate this issue.

:D

On Apr 10, 2012, at 7:55 PM, Dean Willis wrote:

I'm finding that "target" has been heavily overloaded; we have the OMA version, the 3GPP version, Christer's version, old SIP text, and so on.

So I'm confused.

What is the difference between routing and targeting (and retargeting) in your world view?

On Thu, Apr 5, 2012 at 3:29 AM, David Schwartz <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dean

:D

1.  Introduction

---

From: Dean Willis <[email-masked]>
Date: Tue, 10 Apr 2012 22:35:00 -0500

So what's the difference between what is returned by an LUF or an LRF?

I think we can return several things from a query for a TN:

A SIP URI that points ... somewhere. It might be to a terminal SIP UA, it
might be to a gateway, it might be to a proxy, or it might point to a
redirect server. We can't tell which of these it points to by inspection of
the URI. Even if we knew which of these functions it points to, we still
know little about the relationship between the TN we're querying and the
thing that the SIP URI points to, other than that we can "get to" that
telephone number by exercising the URI.

A NAPTR record with sip+e2u tells us little more; it might have priority
variables so that we can rank this information against other responses. But
we still don't know if exercising the NAPTR's URI is going to get us
directly to the termination, or to a transit point, or to another lookup
function.

If we return an NS record, we know we're getting another lookup function,
so that's something. And we know we're going to query that NS, but we don't
know what we're going to get back.

If we return a SPID (whatever that might be), we know we have yet another
model of indirection to go on: the next thing we do is look up routes for
that SPID (presumably, NOT in this registry), then send the request along
those routes, again not knowing what the result will be.

I think you're saying that we need to add more context to the data in the
registry, so that we know what the meaning of a particular "SED record" is,
and how it should be used, and what we expect to gain from exercising that
SED record. You've characterized SED records as either "targets" or
"routes", but I still feel pretty vague about the differences between these
two.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 11 Apr 2012 13:10:06 -0400

If we return an NS record, we know we're getting another lookup function, so
that's something. And we know we're going to query that NS, but we don't
know what we're going to get back.

[RS> ] IN the context of a SED a SPID [Service Provider Identification Code]
is the identifier for Service Provider of Record for the target. 

In NPAC terms its "A NPAC SPID is the OCN of a service provider. This is a
unique four character alphanumeric value. Shown for the owner of each ported
number record in the NPAC. A secondary SPID, called the "alternative SPID,"
also may be associated with a ported number record. This alternative SPID
value may not be an OCN, but instead may be drawn from the series X000 to
X999." 

As most of us know by this time the secondary look up is generally internal
to the originating network and may include route data determined by
bilateral agreement. I think we all generally know what is going on here.
Since some folks did not want to expose their end point target ( the SBC
..duh) topology in a database, he first order resolution was simply to find
who "owns the number" then check my excel spreadsheet for the target URI's
for a particular portability corrected NPA NXX etc.  Make a trunk group
decision ..youre done. Bypass Intercarrier Compensation collect 400 Million
dollars Pass GO become Vice President of some service provider. 

[RS> ] Yep I get this ..it really is the target (aka SBC ) and then the
route ( trunk port at Equinix, 80 Hudson, 1 Wiltshire  ) since the route may
be determined by other factors and use various QoS mechanisms a well.  This
is not the DNS and this is definitely NOT a  best efforts service. 

--
Dean