One document matched: draft-schwartz-drinks-spdist-00.txt
DRINKS D. Schwartz
Internet-Draft XConnect
Intended status: Standards Track J. Barkan
Expires: January 6, 2012 DigitalShtick
July 5, 2011
Session Peering Disribution Protocol
draft-schwartz-drinks-spdist-00
Abstract
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.
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Schwartz & Barkan Expires January 6, 2012 [Page 1]
Internet-Draft draft-schwartz-drinks-spdist July 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Data Model Changes . . . . . . . . . . . . . . . . . . . . 5
2.2. Multiple Data Sources . . . . . . . . . . . . . . . . . . 5
2.3. Multiple Local Repositories . . . . . . . . . . . . . . . 5
2.4. Data Versioning . . . . . . . . . . . . . . . . . . . . . 5
2.5. Availability of Local Repository . . . . . . . . . . . . . 5
2.6. Partitioning Across Stores . . . . . . . . . . . . . . . . 5
2.7. Asynchronous distribution . . . . . . . . . . . . . . . . 5
2.8. Bulk Data Transport Protocol . . . . . . . . . . . . . . . 6
3. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 7
4. SPDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Schwartz & Barkan Expires January 6, 2012 [Page 2]
Internet-Draft draft-schwartz-drinks-spdist July 2011
1. Introduction
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
[I-D.ietf-drinks-usecases-requirements] and the aforementioned
provisioning protocol has been documented in
[I-D.ietf-drinks-spprov]. The reader is expected to be familiar with
the the previously mentioned documents.
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).
*------------* *------------*
(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|
+----------+ +----------+
Three Registry Provisioning Flows
Figure 1
Schwartz & Barkan Expires January 6, 2012 [Page 3]
Internet-Draft draft-schwartz-drinks-spdist July 2011
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 [RFC5486] for more details.
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).
While the provisioning protocol [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.
Schwartz & Barkan Expires January 6, 2012 [Page 4]
Internet-Draft draft-schwartz-drinks-spdist July 2011
2. Rationale
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.
2.1. Data Model Changes
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)?
2.2. Multiple Data Sources
How is this different from multiple provisioning entities? Conflict
mechanism?
2.3. Multiple Local Repositories
Consistency across destination stores. push vs pull. scaling
considerations.
2.4. Data Versioning
full vs incremental synchronization
2.5. Availability of Local Repository
dealing with downtime when trying to distribute.
2.6. Partitioning Across Stores
How do we deal with data partitioning across local stores under a
single administrative domain?
2.7. Asynchronous distribution
Bulk vs incremental distribution
Schwartz & Barkan Expires January 6, 2012 [Page 5]
Internet-Draft draft-schwartz-drinks-spdist July 2011
2.8. Bulk Data Transport Protocol
transport issues associated with bulk transfer
Schwartz & Barkan Expires January 6, 2012 [Page 6]
Internet-Draft draft-schwartz-drinks-spdist July 2011
3. Protocol Commands
TBD
Schwartz & Barkan Expires January 6, 2012 [Page 7]
Internet-Draft draft-schwartz-drinks-spdist July 2011
4. SPDP Examples
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.
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.
---------------+ +------------------
| |
+----------+ SPDP |
| Local |<-----+ |
|Repository| | |
+----------+ | |
| | |
+------+ | +------+
| sbe1 | | | sbe2 |
+------+ | +------+
SSP1 | | | SSP2
+------+ | +------+
| sbe3 | | | sbe4 |
+------+ | +------+
iana-en:111 | | | iana-en:222
---------------+ | +------------------
| |
| |
+------------------+ SPPP |
| Registry |<--------+
+------------------+
Schwartz & Barkan Expires January 6, 2012 [Page 8]
Internet-Draft draft-schwartz-drinks-spdist July 2011
4.1. TBD
TBD
Schwartz & Barkan Expires January 6, 2012 [Page 9]
Internet-Draft draft-schwartz-drinks-spdist July 2011
5. Security Considerations
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.
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.
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.
Schwartz & Barkan Expires January 6, 2012 [Page 10]
Internet-Draft draft-schwartz-drinks-spdist July 2011
6. References
6.1. Normative References
[I-D.ietf-drinks-sppp-over-soap]
Cartwright, K., "SPPP Over SOAP and HTTP",
draft-ietf-drinks-sppp-over-soap-03 (work in progress),
May 2011.
[I-D.ietf-drinks-spprov]
Mule, J., Cartwright, K., Ali, S., and A. Mayrhofer,
"Session Peering Provisioning Protocol",
draft-ietf-drinks-spprov-07 (work in progress),
April 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
6.2. Informative References
[I-D.ietf-drinks-usecases-requirements]
Channabasappa, S., "DRINKS Use cases and Protocol
Requirements", draft-ietf-drinks-usecases-requirements-05
(work in progress), March 2011.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
Schwartz & Barkan Expires January 6, 2012 [Page 11]
Internet-Draft draft-schwartz-drinks-spdist July 2011
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
Architecture", RFC 4725, November 2006.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486,
March 2009.
Schwartz & Barkan Expires January 6, 2012 [Page 12]
Internet-Draft draft-schwartz-drinks-spdist July 2011
Authors' Addresses
David Schwartz
XConnect
Malcha Technology Park
Jerusalem, 96951
Israel
Email: dschwartz@xconnect.net
Jeremy Barkan
DigitalShtick
Jerusalem,
Israel
Email: jbarkan@digitalshtick.com
Schwartz & Barkan Expires January 6, 2012 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 09:02:58 |