One document matched: draft-schwartz-drinks-spdist-00.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2277 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2277.xml">
<!ENTITY rfc2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2781 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2781.xml">
<!ENTITY rfc5321 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY rfc3261 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3263 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml">
<!ENTITY rfc3629 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY rfc3688 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY rfc3986 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc3761 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml">
<!ENTITY rfc4725 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4725.xml">
<!ENTITY rfc5486 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5486.xml">
<!ENTITY I-D.ietf-drinks-usecases-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-drinks-usecases-requirements.xml">
<!ENTITY I-D.ietf-drinks-sppp-over-soap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-drinks-sppp-over-soap.xml">
<!ENTITY I-D.ietf-drinks-spprov SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-drinks-spprov.xml">
]>
<rfc category="std" docName="draft-schwartz-drinks-spdist-00"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="draft-schwartz-drinks-spdist"> Session Peering Disribution
Protocol </title>
<author initials="D.S." surname="Schwartz"
fullname="David Schwartz">
<organization>XConnect</organization>
<address>
<postal>
<street>Malcha Technology Park</street>
<city>Jerusalem</city> <region></region>
<code>96951</code>
<country>Israel</country>
</postal>
<email>dschwartz@xconnect.net</email>
</address>
</author>
<author initials="J.B." surname="Barkan"
fullname="Jeremy Barkan">
<organization>DigitalShtick</organization>
<address>
<postal>
<street></street>
<city>Jerusalem</city> <region> </region>
<code></code>
<country>Israel</country>
</postal>
<email>jbarkan@digitalshtick.com</email>
</address>
</author>
<date year="2011" />
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>DRINKS</workgroup>
<abstract>
<t> This document defines a protocol for distributing session
establishment data from often centralized Session Data
Registries or SIP Service Provider data stores into local data
repositories for local querying of the data. The distributed
data is typically used by various network elements for session
peering. </t>
<t> This document describes the Session Peering Distribution
Protocol (SPDP) that should be seen as an extension to the
session peering provisioning protocol defining
the provisioning process itself. The document
provides a set of guiding principles for the design of this
protocol including an extension of the SPPP basic data model for
distribution purposes and an associated extension XML Schema Document.
</t>
</abstract>
</front>
<middle>
<!-- Note: this is how you can put a note in the draft for yourself or for the co-authors to check on -->
<section anchor="introduction" title="Introduction">
<t> Service providers and enterprises use registries to make
call or session routing decisions for Voice over IP, SMS and
MMS traffic exchanges. This document is narrowly focused on
the distribution protocol, used to take session establishment
data (SED) already provisioned into a registry and distribute
to a local data repository. This protocol prescribes a way for
a registry to distribute to a local cache belonging to a peering
entity, data previously provisioned to the registry by a different
peering entity willing to share its peering data. The requirements
and use cases driving this protocol have been documented in <xref
target="I-D.ietf-drinks-usecases-requirements"/> and the
aforementioned provisioning protocol has been documented in <xref
target="I-D.ietf-drinks-spprov" />. The reader is expected to be
familiar with the the previously mentioned documents.
<vspace blankLines="1"/>
Three types of provisioning flows have been described in the use
case document: client to registry provisioning, registry to
local data repository and registry-to-registry. This document
addresses a subset (distribution of SED from registry-to-local
repository) by defining a Session Peering distribution Protocol
(SPDP) for this purpose (arrow "2" in the figure below).</t>
<t>
<figure align="center" anchor="RegFlows">
<artwork align="center">
<![CDATA[
*------------* *------------*
(1). Provisioning SED | | (3).Registry | |
-----------------------> | Registry |<------------->| Registry |
data into Registries| | to Registry | |
*------------* exchanges *------------*
/ \ \
/ \ v
/ \ ...
/ \
/ (2). \
/ Distributing \
/ SED \
V V
+----------+ +----------+
|Local Data| |Local Data|
|Repository| |Repository|
+----------+ +----------+
]]>
</artwork>
<postamble> Three Registry Provisioning Flows </postamble>
</figure>
</t>
<t> The session establishment data that is distributed to local
repositories 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
<xref target="RFC5486"/> for more details.
<vspace blankLines="1"/>
A "terminating" SIP Service Provider (SSP) provisions SED into
the registry to be selectively shared with other peer 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). </t>
<t>While the provisioning protocol <xref
target="I-D.ietf-drinks-spprov" /> itself made no determination
as to whether or not one common baseline
protocol could be used for all three provisioning flows, this document,
posits the need for an extension to the provisioning protocol to
deal with session data distribution specific issues. To
reiterate, as this document is an extension of the provisioning
document, it is imperative that the reader be familiar
with the provisioning document before starting on this document.
Furthermore, and due to this dependence, SPDP will reuse the
terminology, high level design and the data model sections found
in SPPP and these sections will be omitted from this document. What
this document will provide is the rationale for a separate distribution
protocol, the potentially different transport requirements, the
potentially different security model and the additional protocol
commands and resultant additional xml specification.
</t>
</section>
<section anchor="Rationale" title="Rationale">
<t>While a provisioning protocol must define a data model
representing the data being provisioned, it is not required to
address issues that arise only once the data is actually provisioned.
Data consistency across stores, Data transfer size and
data versioning are only some of the complexities that arise when
attempting to distribute or replicate data from a master to a slave
and the underlying protocol (data model, protocol commands,
transport requirements, etc.) must provide support for the added
functional complexity. This section takes a look at aspects of
data distribution that are different from simple data provisioning.</t>
<section anchor="datamodelchanges" title="Data Model Changes">
<t>What is the SPPP model missing? Do we need data structures
that capture data in manner more efficient for bulk distribution?
Time-stamping (for versioning)?</t>
</section>
<section anchor="multipleregistries" title="Multiple Data Sources">
<t>How is this different from multiple provisioning entities? Conflict
mechanism?</t>
</section>
<section anchor="multiplerepositories" title="Multiple Local Repositories">
<t>Consistency across destination stores. push vs pull. scaling
considerations.</t>
</section>
<section anchor="dataversioning" title="Data Versioning">
<t>full vs incremental synchronization</t>
</section>
<section anchor="datadistribution" title="Availability of Local Repository">
<t>dealing with downtime when trying to distribute.</t>
</section>
<section anchor="datapatitioning" title="Partitioning Across Stores">
<t>How do we deal with data partitioning across local stores under
a single administrative domain?</t>
</section>
<section anchor="dataasynchronous" title="Asynchronous distribution">
<t>Bulk vs incremental distribution</t>
</section>
<section anchor="datatrasnportprotocol" title="Bulk Data Transport Protocol">
<t>transport issues associated with bulk transfer</t>
</section>
</section>
<section anchor="protocol commands" title="Protocol Commands">
<t> TBD</t>
</section>
<section anchor="examples" title="SPDP Examples">
<t>This section shows XML message exchange between a centralized
Registry previously provisioned with Session Establishment Data (SED)
(using the SPPP protocol) by a peering entity SSP2 willing to share
this information, and a local data repository residing at SSP1
(approved by SSP2 to receive this data) needing a copy of SSP2 data.
For the sake of simplicity, the transport wrapper for the SPDP protocol
is left out as well as most of the provisioning messages already
covered in the SPPP document. The SPDP protocol messages in this
section are valid XML instances that conform to the SPDP schema
version within this document.</t>
<t>In this sample use case scenario, SSP2 provisions resource data
to the registry and uses SPPP constructs to selectively
define sharing attributes of the route groups. SPDP is subsequently
used to have this information distributed to relevant local repository.
In the figure below, SSP2 has two ingress SBE instances that are
associated with the public identities that SSP2 has the retail
relationship with.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
---------------+ +------------------
| |
+----------+ SPDP |
| Local |<-----+ |
|Repository| | |
+----------+ | |
| | |
+------+ | +------+
| sbe1 | | | sbe2 |
+------+ | +------+
SSP1 | | | SSP2
+------+ | +------+
| sbe3 | | | sbe4 |
+------+ | +------+
iana-en:111 | | | iana-en:222
---------------+ | +------------------
| |
| |
+------------------+ SPPP |
| Registry |<--------+
+------------------+
]]>
</artwork>
</figure>
</t>
<section anchor="add_..." title="TBD">
<t>TBD</t>
</section>
</section>
<section anchor="securityconsiderations" title="Security Considerations">
<t> SPDP implementations manage data that is considered confidential
and critical. Furthermore, SPDP implementations can support provisioning
activities for multiple registrars and registrants. As a result any
SPDP implementation must address the requirements for confidentiality,
authentication, and authorization.</t>
<t> With respect to confidentiality and authentication, the transport protocol
section contains some security properties that the transport protocol
must provide so that authenticated endpoints can exchange data
confidentially and with integrity protection. </t>
<t> With respect to authorization, the SPDP server implementation must define and
implement a set of authorization rules that precisely address (1) which local
repositories will be authorized to get each SPDP object type for given
registrant(s). These authorization rules are left as a
matter of policy and are not specified within the context of SPDP. However, any
SPDP implementation must specify these authorization rules in order to function
in a reliable and safe manner.</t>
</section>
</middle>
<back>
<references title="Normative References"> &rfc2119; &rfc2277;
&rfc3629; &rfc3688; &rfc3986;
&I-D.ietf-drinks-spprov; &I-D.ietf-drinks-sppp-over-soap; </references>
<references title="Informative References"> &rfc5321; &rfc3261;
&rfc3761; &rfc4725; &rfc5486; &rfc2781;
&I-D.ietf-drinks-usecases-requirements; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:24:56 |