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

[David Schwartz <[e-mail]>]

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:


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


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..."
<ATT00001..c>