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

[Dean Willis <[e-mail]>]

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 <[e-mail]>wrote:

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