DRINKS J-F. Mule Internet-Draft CableLabs Intended status: Standards Track K. Cartwright Expires: September 9, 2010 TNS S. Ali NeuStar A. Mayrhofer enum.at GmbH D. Guyton Telcordia Technologies March 8, 2010 Session Peering Provisioning Protocol draft-mule-drinks-proto-02 Abstract This document defines a protocol for provisioning session establishment data into Session Data Registries and SIP Service Provider data stores. The provisioned data is typically used by various network elements for session peering. This document describes the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol including extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS, and an XML Schema Document. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. Mule, et al. Expires September 9, 2010 [Page 1] Internet-Draft draft-mule-drinks-proto March 2010 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 BSD License. Mule, et al. Expires September 9, 2010 [Page 2] Internet-Draft draft-mule-drinks-proto March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . intro 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . Termi 3. Protocol Definition . . . . . . . . . . . . . . . . . . . . proto 3.1. Protocol Overview and Layering . . . . . . . . . . . . proto 3.2. Data Model . . . . . . . . . . . . . . . . . . . . . . datam 3.2.1. Structure of the SPPP Data Model . . . . . . . . . datam 3.2.2. Data Model Objects and Attributes . . . . . . . . . DataM 3.2.3. Applicability of the Data Model for Provisioning of LUF-only data into Registries . . . . . . . . . DataM 3.2.4. Applicability of the Data Model for Provisioning of LUF+LRF data into Registries . . . . . . . . . . DataM 3.3. Common Attributes . . . . . . . . . . . . . . . . . . . commo 3.3.1. Common Organization Attributes . . . . . . . . . . commo 3.3.2. Common Attributes for Activation and Deletion Dates commo 3.4. Known Issues and Current Limitations of the Data Model openi 4. Transport Protocol Requirements . . . . . . . . . . . . . . trans 4.1. Connection Oriented . . . . . . . . . . . . . . . . . . trans 4.2. Request & Response Model . . . . . . . . . . . . . . . reque 4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . conne 4.4. Authentication . . . . . . . . . . . . . . . . . . . . authe 4.5. Confidentiality & Integrity . . . . . . . . . . . . . . confi 4.6. Near Real Time . . . . . . . . . . . . . . . . . . . . timin 4.7. Request & Response Sizes . . . . . . . . . . . . . . . resps 4.8. Request and Response Correlation . . . . . . . . . . . reqor 4.9. Request Acknowledgement . . . . . . . . . . . . . . . . ack 4.10. Mandatory Transport . . . . . . . . . . . . . . . . . . manda 5. XML Considerations . . . . . . . . . . . . . . . . . . . . xmlco 5.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . names 5.2. Versioning . . . . . . . . . . . . . . . . . . . . . . versi 6. Request and Reply Model . . . . . . . . . . . . . . . . . . Reque 6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . reque 6.2. Reply . . . . . . . . . . . . . . . . . . . . . . . . . reply 7. Response Codes and Messages . . . . . . . . . . . . . . . . resul 8. Protocol Commands . . . . . . . . . . . . . . . . . . . . . proto 8.1. List of Protocol Commands . . . . . . . . . . . . . . . comma 8.2. Example Command Description . . . . . . . . . . . . . . comma 8.2.1. deleteDestinationGroup . . . . . . . . . . . . . . Delet 9. Security Considerations . . . . . . . . . . . . . . . . . . secur 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . IANA 11. Formal Specification . . . . . . . . . . . . . . . . . . . forma 12. Specification Extensibility . . . . . . . . . . . . . . . . speci 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . ancho 14. References . . . . . . . . . . . . . . . . . . . . . . . . ancho 14.1. Normative References . . . . . . . . . . . . . . . . . ancho 14.2. Informative References . . . . . . . . . . . . . . . . ancho Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 0 Mule, et al. Expires September 9, 2010 [Page 3] Internet-Draft draft-mule-drinks-proto March 2010 1. Introduction Several registries are used by service providers and enterprises on the Internet today to assist them in making call or session routing decisions for Voice over IP, SMS and MMS traffic exchanges. This document is narrowly focused on the provisioning protocol for these registries. The problem space this protocol attempts to solve is: how can entities use a common protocol to provision session- related data into those registries so that their communication peers can query it. Multiple company-proprietary solutions exist with different different data models and protocol operations. The requirements and use cases driving this protocol have been documented in [I-D.ietf-drinks-usecases-requirements]. The reader is expected to be familiar with the terminology defined in the previously mentioned document. 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 (client-to-registry provisioning) by defining a Session Peering Provisioning Protocol (SPPP) for provisioning Session Establishment Data (SED) into a Registry (arrow numbered one in the figure below). While the other "provisioning flows" are shown below as separate message flows, no determination has been made for whether one common baseline protocol could be used for all three, or whether distinct protocols are required. Mule, et al. Expires September 9, 2010 [Page 4] Internet-Draft draft-mule-drinks-proto March 2010 *------------* *------------* (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| +----------+ +----------+ 3 Registry Provisioning Flows Figure 1 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. The SED is typically created by the terminating SIP Service Provider (SSP) for use by the originating SSP. SED is provisioned into a Registry shared by peer SSPs as part of their service provisioning process. Subsequently, a Registry may distribute the received data into local Data Repositories that can be queried to support session look-up queries (identifier -> target domain) or for lookup and location resolution (identifier -> target domain -> ingress SBE of terminating SSP). In some cases, the Registry may additionally offer a central query resolution service (not shown in the above figure). A key requirement for the SPPP protocol is to be able to accommodate two basic scenarios deployed in production today: 1. The Registry only serves for the Look-Up function (LUF) to determine for a given request the target domain to which the Mule, et al. Expires September 9, 2010 [Page 5] Internet-Draft draft-mule-drinks-proto March 2010 request should be routed (as described in [RFC5486]). Other means are used by peers to perform the Location Routing Function (LRF) which determines for the returned target domain the actual location of the Signaling Function in that domain. 2. The Registry serves for both the Look-Up function (LUF) and the Location Routing Function (LRF), helping develop the SED data fully. In terms of protocol design, this document specifies a protocol agnostic to its transport. It provides a description of the data model, the protocol operations including the model for request and responses, and most of the needed protocol commands. Reviews are encourage to determine if the proposed model meets the requirements and to improve or change some of the protocol constructs. The protocol also allows for some extensibility with guidelines to manage such extensibility and to achieve interoperability. Transport requirements are provided with the intention that each underlying transport protocol will be defined in another document. Current transport protocols under consideration include one based on SOAP ([I-D.cartwright-drinks-sppp-over-soap]), one based on the RESTful Web Services approach (for further study) and a file transfer mechanism for batch mode protocol operations (for further study). This document is organized as follows: o Section 3 provides an overview of the SPPP protocol, including the layering approach, functional entities and data model; o Section 4 defines requirements for SPPP transport protocols; o Section 5 defines XML considerations that XML parsers must meet to conform to this specification. o Section 6 describes the protocol request-reply model; o Section 8 defines the protocol commands for this version of SPPP, and how to extend them; Future revisions of this Internet-Draft will include a more complete definition of the Session Peering Provisioning Protocol and considerations and changes to make the protocol implementable using SOAP and RESTful Web Services. Mule, et al. Expires September 9, 2010 [Page 6] Internet-Draft draft-mule-drinks-proto March 2010 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document reuses terms from [RFC3261], [RFC5486], the DRINKS Use Case and Requirements document [I-D.ietf-drinks-usecases-requirements] and the ENUM Validation Architecture [RFC4725]. In addition, this document specifies the following additional terms. SPPP: Session Peering Provisioning Protocol, the protocol used to provision data into a Registry (see arrow labeled "1." in Figure 1 of [I-D.ietf-drinks-usecases-requirements]). It is the primary scope of this document. SPDP: Session Peering Distribution Protocol, the protocol used to distribute data to Local Data Repository (see arrow labeled "2." in Figure 1 of [I-D.ietf-drinks-usecases-requirements]). Client: An application that supports an SPPP Client; it is sometimes referred to as a "Registry Client". Registry: The Registry operates a master database of Session Establishment Data for one or more Registrants. A Registry acts as an SPPP Server. Registrant: In this document, we extend the definition of a Registrant based on [RFC4725]. The Registrant is the end-user, the person or organization who is the "holder" of the Session Establishment Data being provisioned into the Registry. For example, in [I-D.ietf-drinks-usecases-requirements], a Registrant is pictured as a SIP Service Provider in Figure 2. A Registrant is identified by its name in the data model. Mule, et al. Expires September 9, 2010 [Page 7] Internet-Draft draft-mule-drinks-proto March 2010 Registrar: In this document, we also extend the definition of a Registrar from [RFC4725]. A Registrar performs provisioning operations on behalf of a Registrant by interacting with the Registry, in our case via the SPPP protocol defined in this document. A Registrar is identified by its name in the data model. Mule, et al. Expires September 9, 2010 [Page 8] Internet-Draft draft-mule-drinks-proto March 2010 3. Protocol Definition This section introduces the structure of the data model and provides the information framework for the SPPP protocol. An overview of the protocol operations is first provided with a typical deployment scenario. The data model is then defined along with all the objects manipulated by the protocol and their relationships. 3.1. Protocol Overview and Layering SPPP is a simple request/reply protocol that allows a client application to submit provisioning data and query requests to a server. The SPPP data structures are designed to be protocol agnostic. As a result, the underlying transport technology, messaging envelope technology (if any), and the authentication scheme are not limited or defined by this specification. However, refer to the Transport Protocol Requirements section for assumptions that are made about the chosen transport, envelope, and authentication technologies. Layer Example +-------------+ +-----------------------------+ (5) |Data Objects | | RteGrpType, etc. | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (4) | Operations | | addRteGrpsRqst, etc. | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Message | | spppRequest, spppResponse | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | Message | | HTTP, SOAP, None, etc. | | Envelope | | | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Transport | | TCP, TLS, BEEP, etc. | | Protocol | | | +-------------+ +-----------------------------+ SPPP Layering Figure 2 Mule, et al. Expires September 9, 2010 [Page 9] Internet-Draft draft-mule-drinks-proto March 2010 SPPP can be viewed as a set of layers that collectively define the structure of an SPPP request and response. Layers 3, 4, and 5 are defined within this specification, while layers 1 and 2 are left to separate specifications to allow for potentially multiple SPPP transport, envelope, and authentication technologies. 1. The transport protocol layer provides a communication mechanism between the client and server. SPPP can be layered over any transport protocol that provides a set of basic requirements defined in the Transport Protocol Requirements section. 2. The message envelope layer is optional, but can provide features that are above the transport technology layer but below the application messaging layer. Technologies such as HTTP and SOAP are examples of messaging envelope technologies. 3. The message layer provides a simple, envelope-independent and transport-independent, SPPP wrapper for SPPP request and response messages. 4. The operation layer defines the set of base SPPP actions that can be invoked using an SPPP message. Operations are encoded using XML encoded actions and objects. 5. The data object layer defines the base set of SPPP data objects that can be included in update operations or returned in operation responses. 3.2. Data Model The data model illustrated and described in Figure 3 defines the logical objects and the relationships between these objects that the SPPP protocol supports. SPPP defines the protocol operations through which an SPPP Client populates a Registry with these logical objects. Various clients belonging to different Registrants and distinct Registrars may use the protocol for populating the Registry's data. 3.2.1. Structure of the SPPP Data Model The logical structure presented below is consistent with the terminology and requirements defined in [I-D.ietf-drinks-usecases-requirements]. Note that the current version of this data model does not yet address the notion of Data Recipient Groups (left for a future revision of this document). +-------------+ +------------------+ | all object | |Organization: | Mule, et al. Expires September 9, 2010 [Page 10] Internet-Draft draft-mule-drinks-proto March 2010 | types | |orgName*, | +------+------+ |sourceIdentLabels,| +------------>|peerPrefs, | |extension | All objects are | | associated with 2 | | Organizations to +------------------+ identify the ^ registrant and |A Route Group is the registrar |associated with |zero or more |Organizations | +-----------------------+ |Route Group: | +----------------+ | registrantOrgName*, | | | | registrarOrgName, | | Route Record: | | rteGrpName*, | | rteRecName*, | | targetDomain, +------->| priority, | | isInService, | | extension | | resRecs, | | | | sourceOrgs, | +----------------+ | sourceIdentLabels, | ^ | activationDate, | |Various types | deletionDate, | |of Route | extension | |Records... | | � +-----------------------+ � ^ | +---------+------------+ |Destination | |Group: | | registrantOrgName*, | | registrarOrgName, | | destGroupName*, | +--->| routeGrpNames*, |<----+ | | activationDate, | | | | deletionDate, | | | | extension | | | +----------------------+ | | | A TNRange is A Public | associated Identifier is | with only 1 associated | Destination with zero or | Group. 1 Destination Group. | | Mule, et al. Expires September 9, 2010 [Page 11] Internet-Draft draft-mule-drinks-proto March 2010 +----------------------+ +-------------+---------+ |TNRange: | |Public | | registrantOrgName*, | |Identifier: | | registrarOrgName, | | registrantOrgName*, | | tnRangeStart*, | | registrarOrgName, | | tnRangeEnd*, | | publicIdentifier*, | | destGroupName*, | | destGroupName*, | | activationDate, | | publicIdTarget, | | deletionDate, | | | | extension | | activationDate, | | | | deletionDate, | | | | extension | +----------------------+ +-----------------------+ Second Data Model for SPPP for WG Review Figure 3 Note that the attributes whose names end with the character * are mandatory attributes. 3.2.2. Data Model Objects and Attributes The objects and attributes that comprise the data model can be described as follows (objects listed from the bottom up): o Public Identifier (publicIdentifier): A string of numbers or characters that serves as a public identifier. A Public Identifier may be a telephone number, an email address, a PSTN routing number or other type of identity as deemed appropriate. The Public Identifier object may be associated with a Destination Group which serves as a logical grouping of identifiers that share a common group of Routes. A Public Identifier may optionally be associated with zero or more individual route records. This ability for a Public Identifier to be directly associated with a set of routes (e.g. target URI), as opposed to being associated with a Destination Group, supports the use cases where the target URI contains data specifically tailored to an individual Public Identifier. o Telephone Number Range (TNRange, tnRangeStart .. tnRangeEnd): An object that represents an inclusive range of telephone numbers. The TNRange object must be associated with a Destination Group which indirectly defines the route to reach the TNs in that range. Mule, et al. Expires September 9, 2010 [Page 12] Internet-Draft draft-mule-drinks-proto March 2010 o Destination Group (destGroupName): A collection of zero or more Public Identifiers and Telephone Number ranges (TNRanges) that are related to one or more Route Group relationships. o Route Group (rteGrpName): A Route Group contains a target domain (for Look-Up Function resolutions) and it may contain a collection of Route Record objects that can be used to determine the Location Routing of a SIP route. A Route Group can be in or out of service (indicated by isInService). It also contains a list of organizations that can query the object and have access to its content (sourceOrgs and sourceIdentLabels), and an activation and deletion date. o Source Identity Labels attribute (sourceIdentLabels): A character string that identifies the source of a resolution lookup and can be used for source-based routing. o Route Record of different types (rteRec): A collection of route records; the currently defined types are mapped to DNS Resource Records such as NAPTR, NS, TXT, etc. A Route Record object represents data that resolution systems use to return a route by building a NAPTR record or a SIP 3xx message. It is associated with a Route Group for routes that are not specific to a public identifier. An Route Record object has a name (rteRecName), a priority to help sort out the order of multiple routes (priority can be mapped to NAPTR's order field), and additional elements based on its type. o Organization (orgName): Represents an organization (which can be a registrant, a registrar or an organization that is authorized to view the data such as peer SSPs). A peer preference is also represented (peerPrefs). All objects are associated with two organizations to identify the registrant and the registrar. 3.2.3. Applicability of the Data Model for Provisioning of LUF-only data into Registries This section provides a read-out of the data model for SPPP clients that only provision data for LUF resolution. The purpose of LUF data provisioning is to provide the target domain given a destination group. As such, a client provisioning LUF-only data only needs to provide one or more route groups that contain a route group name and a target domain. Mule, et al. Expires September 9, 2010 [Page 13] Internet-Draft draft-mule-drinks-proto March 2010 Note that source-based routing is supported: depending on what entity requests the look-up resolution (sourceOrgs), a different target domain can be returned by using different Route Groups. Certain protocol operations could be added in future revisions of this document as "short-cuts" for LUF related data provisioning. +-----------------------+ |Route Group: | | rteGrpName*, | | isInService, | | targetDomain, | | extension | | | +-----------------------+ ^ | +---------+------------+ |Destination | |Group: | | destGroupName*, |<----+ | routeGrpNames*, | | | extension | | +----------------------+ | | +-------------+---------+ |Public | |Identifier: | | publicIdentifier*, | | destGroupName*, | | extension | +-----------------------+ LUF-only Data Model Example for SPPP for DRINKS WG Review Figure 4 As an example, a request to add a route group where public identifiers resolve into the target domain ssp1.example.com during look-up resolution would be: Mule, et al. Expires September 9, 2010 [Page 14] Internet-Draft draft-mule-drinks-proto March 2010 id-12317123 20 registrantID123 registrarId0 2010-05-04T18:13:51.0Z 2010-05-04T18:13:51.0Z route_grp_1 ssp1.example.com true Figure 5 3.2.4. Applicability of the Data Model for Provisioning of LUF+LRF data into Registries This section provides a read-out of the data model for SPPP clients that provision data for both LUF and LRF resolution. The purpose of LUF+LRF data provisioning is to provide the target domain given a destination group as well as the location routing for that target domain. As such, a client provisioning LUF+LRF data provides one or more route groups that contain a route group name and a target domain and each route group is associated with a Route Record which can be in the form of a URI, or a DNS resource record (NAPTR, NS or TXT). Mule, et al. Expires September 9, 2010 [Page 15] Internet-Draft draft-mule-drinks-proto March 2010 +-----------------------+ |Route Group: | +----------------+ | rteGrpName*, | | | | isInService, | | Route Record: | | targetDomain, +------->| rteRecName*, | | extension | | priority, | | | | extension | +-----------------------+ | ^ +----------------+ | +---------+------------+ |Destination | |Group: | | destGroupName*, |<----+ | routeGrpNames*, | | | extension | | +----------------------+ | | +-------------+---------+ |Public | |Identifier: | | publicIdentifier*, | | destGroupName*, | | extension | +-----------------------+ LUF+LRF Data Model Example for SPPP for DRINKS WG Review Figure 6 As an example, a request to add a route group where public identifiers resolve into the target domain ssp1.example.com and NAPTR associated with that domain based on the source Organization would be: Mule, et al. Expires September 9, 2010 [Page 16] Internet-Draft draft-mule-drinks-proto March 2010 id-12317123 20 registrantID123 registrarId0 2010-05-04T18:13:51.0Z 2010-05-04T18:13:51.0Z route_grp_1 ssp1.example.com true 10 100 u E2U+sip ^(.*)$ sip:\1;npdi@sbe34-ssp1.example.com; true Figure 7 3.3. Common Attributes This section defines common object attributes. The protocol exchanges and operations in SPPP take various parameters. Some of these are common to several objects. 3.3.1. Common Organization Attributes Two organization roles have been identified in the use cases and in this protocol. A registrant (registrantOrgName) is the organization or business entity that "owns" the object while a registrar is an Mule, et al. Expires September 9, 2010 [Page 17] Internet-Draft draft-mule-drinks-proto March 2010 entity that can provision an object. 3.3.2. Common Attributes for Activation and Deletion Dates An object's activation date (activationDate) indicates when the date at which an object becomes active or valid. Prior to that date, the object may be stored in the data repository but queries linked with the object will return responses as if the object did not exist. An object's deletion date (deletionDate) is the date at which an object is deleted from the data repository. 3.4. Known Issues and Current Limitations of the Data Model The data model described in Figure 3 is a preliminary version that does not address the following needs and requirements: o Some use cases and requirements contained in [I-D.ietf-drinks-usecases-requirements] such as Data Recipient Groups and Points of Egress to name a few were left out of scope of this version based on the design team consensus. Some require further discussions to be best addressed in the protocol; other will be added in future revisions of this document. o The support of the selection of a Route Group for a Public Identifier that belongs to two or more Destination Groups is a known issue. It is required to add some additional atribute(s) to allow the selection of a route group by preference, by the type of route (transit SSP vs. carrier-of-record SSP) or by some other means. o Parts of the proposed draft XML Schema Definition (XSD) may have to change to accomodate various protocol implementations using SOAP and REST. For example, the way the basic request type is defined in the XSD may not be suitable for REST-like protocols and the atomic XML element definitions for add, delete and get operations on most of objects are not friendly to the RESTful Web Services model that employs PUT, GET, and other HTTP operations for those commands. It is expected that future revisions of this document will address some if not all of the limitations or known issues documented above. Mule, et al. Expires September 9, 2010 [Page 18] Internet-Draft draft-mule-drinks-proto March 2010 4. Transport Protocol Requirements This section provides requirements for transport protocols suitable for SPPP. More specifically, this section specifies the services, features, and assumptions that SPPP delegates to the chosen transport and envelope technologies. Two different groups of use cases are specified in [I-D.ietf-drinks-usecases-requirements]. One group of use cases describes the provisioning of data by a client into a Registry (Section 3.1 of the above referenced document), while the other group describes the distribution of data into local data repositories (Section 3.2). The current version of this document focuses on the first set of use cases (client to registry provisioning). These use cases may involve the provisioning of very small data sets like the modification or update of a single public identifier. Other provisioning operations may deal with huge datasets like the "download" of a whole local number portability database to a Registry. As a result, a transport protocol for SPPP must be very flexible and accommodate various sizes of data set sizes. For the reasons outlined above, it is conceivable that provisioning and distributing may use different transport protocols. This document focuses on the provisioning protocol. A few topics remain open for discussion: o The ability to establish multiple connections between a client and server may be desirable. If so, we may want to specify the relation of transactions between the various connections. o Pipelining of requests is required at the SPPP protocol layer. It may have impacts at the transport level that need to be outlined. o Scope: the current scope of this effort is based upon having a connection oriented transport. Is there any need to support a transport protocol with asynchronous operation? o If it is required that responses arrive in the order of the requests, this must be specified clearly. Mule, et al. Expires September 9, 2010 [Page 19] Internet-Draft draft-mule-drinks-proto March 2010 4.1. Connection Oriented The SPPP protocol follows a model where a Client establishes a connection to a Server in order to further exchange provisioning transactions over such point-to-point connection. A transport protocol for SPPP MUST therefore be connection oriented. Note that the role of the "Client" and the "Server" only applies to the connection, and those roles are not related in any way to the type of entity that participates 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 SSP). 4.2. Request & Response Model Provisioning operations in SPPP follow the request - response model, where a transaction is initiated by a Client using a Request command, and the Server responds to the Client by means of a Response. Multiple subsequent request-response exchanges MAY be performed over a single connection. Therefore, a transport protocol for SPPP MUST follow the request- response model by allowing a response to be sent to the request initiator. 4.3. Connection Lifetime Some use cases involve provisioning a single request to a network element - connections supporting such provisioning requests might be short-lived, and only established on demand. Other use cases involve either provisioning a huge set of data, or a constant stream of small updates, which would require long-lived connections. Therefore, a protocol suitable for SPPP SHOULD support short lived as well as long lived connections. 4.4. Authentication Many use cases require the Server to authenticate the Client, and potentially also the Client to authenticate the Server. While authentication of the Server by the Client is expected to be used only to prevent impersonation of the Server, authentication of the Client by the Server is expected to be used to identify and further authorize the Client to certain resources on the Server. Mule, et al. Expires September 9, 2010 [Page 20] Internet-Draft draft-mule-drinks-proto March 2010 Therefore, an SPPP transport protocol MUST provide means for a Server to authenticate and authorize a Client, and MAY provide means for Clients to authenticate a Server. However, SPPP transport SHOULD also allow for unauthenticated connections. 4.5. Confidentiality & Integrity Data that is transported over the protocol is deemed confidential. Therefore, a transport protocol suitable for SPPP MUST ensure confidentiality and integrity protection by providing encryption capabilities. Additionally, a DRINKS protocol MUST NOT use an unreliable lower- layer transport protocol that does not provide confidentiality and integrity protection. 4.6. Near Real Time Many use cases require near real-time responses from the Server. Therefore, a DRINKS transport protocol MUST support near-real-time response to requests submitted by the Client. 4.7. Request & Response Sizes SPPP covers a range of use cases - from cases where provisioning a single public identifier will create very small request and response sizes to cases where millions of data records are submitted or retrieved in one transaction. Therefore, a transport protocol suitable for SPPP MUST support a great variety of request and response sizes. A transport protocol MAY allow splitting large chunks of data into several smaller chunks. 4.8. Request and Response Correlation A transport protocol suitable for SPPP MUST allow responses to be correlated with requests. 4.9. Request Acknowledgement Data transported in the SPPP protocol is likely crucial for the operation of the communication network that is being provisioned. Failed transactions can lead to situations where a subset of public identifiers (or even SSPs) might not be reachable, or situations Mule, et al. Expires September 9, 2010 [Page 21] Internet-Draft draft-mule-drinks-proto March 2010 where the provisioning state of the network is inconsistent. Therefore, a transport protocol for SPPP MUST provide a Response for each Request, so that a Client can identify whether a Request succeeded or failed. 4.10. Mandatory Transport As of this writing of this revision, one transport protocol proposal has been provided in [I-D.cartwright-drinks-sppp-over-soap]. This section will define a mandatory transport protocol to be compliant with this RFC. Mule, et al. Expires September 9, 2010 [Page 22] Internet-Draft draft-mule-drinks-proto March 2010 5. XML Considerations XML serves as the encoding format for SPPP, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation. This section discusses a small number of XML-related considerations pertaining to SPPP. 5.1. Namespaces All SPPP protocol elements are defined in the following namespace: urn:ietf:params:xml:ns:sppp:base:1 Namespace and schema definitions are used to identify both the base protocol schema and the schemas for managed objects. 5.2. Versioning All XML instances SHOULD begin with an declaration to identify the version of XML that is being used, optionally identify use of the character encoding used, and optionally provide a hint to an XML parser that an external schema file is needed to validate the XML instance. Conformant XML parsers recognize both UTF-8 (defined in [RFC3629]) and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the RECOMMENDED character encoding for use with SPPP. Character encodings other than UTF-8 and UTF-16 are allowed by XML. UTF-8 is the default encoding assumed by XML in the absence of an "encoding" attribute or a byte order mark (BOM); thus, the "encoding" attribute in the XML declaration is OPTIONAL if UTF-8 encoding is used. SPPP clients and servers MUST accept a UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED. Example XML declarations: version="1.0" encoding="UTF-8" standalone="no"?> Mule, et al. Expires September 9, 2010 [Page 23] Internet-Draft draft-mule-drinks-proto March 2010 6. Request and Reply Model An SPPP client interacts with an SPPP server by using one of the supported transport mechanisms to send one or more requests to the server and receive corresponding replies from the server. An SPPP request is wrapped within the element while an SPPP reply is wrapped within an element. Furthermore, fully formed SPPP requests and replies are comprised of constructs required by the chosen transport technology, and the chosen envelope technology. The supported transport technology and envelope technology specifications will be defined in separate documents, and are not discussed here. 6.1. Request An SPPP request object, common to any transport and envelope technology, is contained within the generic element. Within any element is the request object specific to the type of object(s) being operated on and the action(s) being performed on that object. For example, the addRteGroupRqst object, used to create Route Groups, that would be passed within an is defined as follows: Mule, et al. Expires September 9, 2010 [Page 24] Internet-Draft draft-mule-drinks-proto March 2010 All update requests contain a BasicRqstType object. This object is defined as follows: The data elements within the BasicRqstType object are primarily "house keeping" data elements. They are described as follows: o clientTransId: The client generated transaction ID that identifies this request for tracking purposes. This value is also echoed back to the client in the response. This value will not be checked for uniqueness. o minorVer: This identifies the minor version of the SPPP API that the client is attempting to use. This is used in conjunction with the major version identifier in the XML namespace. Refer to the Versioning section of this document for more detail. o ext: This is the standard extension element for this object. Refer to the Extensibility section of this document for more details. Mule, et al. Expires September 9, 2010 [Page 25] Internet-Draft draft-mule-drinks-proto March 2010 6.2. Reply An SPPP reply object, common to any transport and envelope technology, is contained within the generic element. Within any element is the reply object containing the result of the request. All create, update, and delete operations result in a common response object structure, defined as follows: Mule, et al. Expires September 9, 2010 [Page 26] Internet-Draft draft-mule-drinks-proto March 2010 The data elements within the BasicRspnseType object are described as follows: o clientTransId: The echoed back client transaction ID that explicitly identifies this request for tracking purposes. This value is not guaranteed to be unique. o serverTransId: The server transaction ID that identifies this request for tracking purposes. This value is guaranteed to be unique. o resCode: The response code that explicitly identifies the result of the request. See the Response Code section for further details. o resMsg: The human readable response message that accompanies the response code. See the Response Code section for further details. o ext: This is the standard extension element for this object. Refer to the Extensibility section for more details. Mule, et al. Expires September 9, 2010 [Page 27] Internet-Draft draft-mule-drinks-proto March 2010 7. Response Codes and Messages This section contains an initial listing of response codes and their corresponding human readable text. The response code numbering scheme generally adheres to the theory formalized in section 4.2.1 of [RFC2821]: o The first digit of the response code can only be 1 or 2: 1 = a positive result, 2 = a negative result. o The second digit of the response code indicates the category: 0 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = Security, 3 = Server System. o The third and fourth digits of the response code indicate the individual message event within the category defines by the first two digits. +--------+----------------------------------------------------------+ | Result | Text | | Code | | +--------+----------------------------------------------------------+ | 1000 | Request Succeeded. | | | | | 2001 | Request syntax invalid. | | | | | 2002 | Request too large. | | | | | 2003 | Version not supported. | | | | | 2103 | Command invalid. | | | | | 2104 | Attribute value invalid: [attribute name]:[attribute | | | value]:[objectType-objectId]. | | | | | 2105 | Object does not exist: [attribute name] : | | | [objectType-objectId]. | | | | | 2106 | Object status or ownership does not allow for request: | | | [request name]:[ attributeName]:[objectType-objectId]. | | | | | 2301 | System temporarily unavailable. | | | | | 2302 | Unexpected internal system or server error. | +--------+----------------------------------------------------------+ Table 1: Response Codes Numbering Scheme and Messages Mule, et al. Expires September 9, 2010 [Page 28] Internet-Draft draft-mule-drinks-proto March 2010 Some response messages are "parameterized" with one or more of the following parameters: "attribute name", "attribute value", "objectType-objectId", and "operation name". The use of these parameters MUST adhere to the following rules: o All parameters within a response message are mandatory and MUST be present. Parameters within a response message MUST NOT be left empty. o Any value provided for the "attribute name" parameter MUST be an exact element name of the protocol data element that the response message is referring to. For example, allowable values for "attribute name" are "destGrpName", "rteGrpName", etc. o A value provided for the "command/request type" parameter MUST be an exact request object name that the response message is referring to. For example, an allowable value for "request object name" is "delRteGrpsRqst". o The value for "attribute value" MUST be the value of the data element to which the preceding "attribute name" refers. o Result code 2104 SHOULD be used whenever an element value does not adhere to data validation rules. o Result codes 2104 and 2105 MUST NOT be used interchangeably. Response code 2105 SHOULD be returned when the data element(s) used to uniquely identify a pre-existing object do not exist. If the data elements used to uniquely identify an object are malformed, then response code 2104 SHOULD be returned. Mule, et al. Expires September 9, 2010 [Page 29] Internet-Draft draft-mule-drinks-proto March 2010 8. Protocol Commands This section provides a preliminary list of SPPP protocol commands. At this early stage of the protocol development, the commands are only listed with a brief description. An example of how a complete command description might look is contained in section Section 8.2. It is expected that as the protocol commands get more stable, full descriptions will be provided in future revisions. 8.1. List of Protocol Commands The commands listed below are briefly described - the primary goal of this section in this second revision of the document is to give an overview of the envisioned commands for SPPP. It is noted that some commands are missing and the authors seek the input of the WG for the necessary commands. By design, the protocol operations are restricted to add, delete and get operations. There is no "update" or "modify" command. It is felt that an "add" operation should be sufficient to update a particular element set. For an actual business process to be performed, several commands are being typically combined. add Route Group (addRteGrpsRqst): A Route Group" object is created or updated with the attributes given in the command. del Route Group (delRteGrpsRqst): A Route Group object is removed. The object must be owned by the client, and must not be refered from other objects. get Route Group (getRteGrpsRqst): Returns Attributes of a given Route Group object. add, delete and get Destination Group (addDestGroupsRqst, delDestGroupsRqst, getDestGroupsRqst): A Destination Group object is created or updated with the attributes given in the addDestGroupsRqst command; it is deleted with delDestGroupsRqst and its data can be returned using getDestGroupsRqst. add, delete and get Public Identifier (addPubIdsRqst, delPubIdsRqst, getPubIdsRqst) Mule, et al. Expires September 9, 2010 [Page 30] Internet-Draft draft-mule-drinks-proto March 2010 add, delete and get TNRange (addTNRsRqst, delTNRsRqst, getTNRsRqst) Other commands For this version and to get a list of the additional commands, please refer to the XSD in Section 11. Reviewers of this document are invited to provide feedback on the first list of proposed commands. //TODO in a future revision: add more details as the draft gets more stable. 8.2. Example Command Description As outlined above, the preliminary list of commands provides only an overview of the set of possible commands, rather than a full normative specification. This section contains an example of what a full specification could contain. A full specification of all commands supported for v1.0 of SPPP will be provided in a subsequent version of this draft. 8.2.1. deleteDestinationGroup delDestGroupsRqst This command requests the deletion an existing Destination Group object. Support for this command is REQUIRED in Servers, and RECOMMENDED in Clients. This command requires a single mandatory attribute, namely the "destGroupName". The value of this attribute is used to identify the Destination Group object instance that is to be deleted. For the command to succeed, the following prerequisites must be met: o The Destination Group identified by the "destGroupName" attribute of the command must exist. If the Destination group does not exist, an error code (TBD) is to be returned. o The command must be issued by the registrar that is identified by the "registrarOrgName" of the Destination Group that is being deleted. However, local server policy may override this prerequisite, and grant permission to "foreign" registrars. If delete permission is not granted, the error code (TBD) is to be returned. o No TNRange object and no Public Identifier object must be associated with the Destination Group to be deleted. If there is Mule, et al. Expires September 9, 2010 [Page 31] Internet-Draft draft-mule-drinks-proto March 2010 a TNRange or a Public Identifier object associated with this Destination Group, the error code (TBD) is to be returned. Once the prerequisites are fulfilled, the Registry performs the following actions: o The "deletionDate" attribute of the Destination Group is set to the current date. o The Destination Group object is removed. o Depending on local server policy, a notify message is sent to the Registrant (identified by the "registrantOrgName" attribute) The command may return the following response codes: TBD. This command is not extensible. Mule, et al. Expires September 9, 2010 [Page 32] Internet-Draft draft-mule-drinks-proto March 2010 9. Security Considerations 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. More details will be provided in a future revision of this document. Mule, et al. Expires September 9, 2010 [Page 33] Internet-Draft draft-mule-drinks-proto March 2010 10. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments are requested. Registration request for the SPPP XML namespace: urn:ietf:params:xml:ns:sppp:base:1 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification. Registration request for the XML schema: URI: urn:ietf:params:xml:schema:sppp:1 Registrant Contact: IESG XML: See the "Formal Specification" section of this document (Section 11). Mule, et al. Expires September 9, 2010 [Page 34] Internet-Draft draft-mule-drinks-proto March 2010 11. Formal Specification This section provides the draft XML Schema Definition for the SPPP protocol. Please read Section 3.4 for known issues. ------------------ Object Type Definitions -------------- Mule, et al. Expires September 9, 2010 [Page 35] Internet-Draft draft-mule-drinks-proto March 2010 Mule, et al. Expires September 9, 2010 [Page 36] Internet-Draft draft-mule-drinks-proto March 2010 Mule, et al. Expires September 9, 2010 [Page 37] Internet-Draft draft-mule-drinks-proto March 2010 Mule, et al. Expires September 9, 2010 [Page 38] Internet-Draft draft-mule-drinks-proto March 2010 -------------- Wrapped Rqst Message Definitions ------------ Mule, et al. Expires September 9, 2010 [Page 39] Internet-Draft draft-mule-drinks-proto March 2010 Mule, et al. Expires September 9, 2010 [Page 41] Internet-Draft draft-mule-drinks-proto March 2010 -------- Wrapped Rspns Message Definitions --------------- Mule, et al. Expires September 9, 2010 [Page 42] Internet-Draft draft-mule-drinks-proto March 2010 Mule, et al. Expires September 9, 2010 [Page 43] Internet-Draft draft-mule-drinks-proto March 2010 Mule, et al. Expires September 9, 2010 [Page 44] Internet-Draft draft-mule-drinks-proto March 2010 12. Specification Extensibility The protocol defined in this specification is extensible. This section explains how to extend the protocol and what procedures are necessary to follow in order to ensure proper extensions. //TODO in a future revision: add more details as the draft gets more stable. Mule, et al. Expires September 9, 2010 [Page 45] Internet-Draft draft-mule-drinks-proto March 2010 13. Acknowledgments This document is a result of various discussions held in the DRINKS working group and within the DRINKS protocol design team, which is comprised of the following individuals, in alphabetical order: Deborah A Guyton (Telcordia), Sumanth Channabasappa (CableLabs), Jean-Francois Mule (CableLabs), Kenneth Cartwright (TNSI), Manjul Maharishi (TNSI), Spencer Dawkins (Huawei Technologies (USA)), and the co-chairs Richard Shockey and Alexander Mayrhofer (enum.at GmbH). The authors of this document thank the following individuals for their advice, reviews and comments during the development of this protocol: Lisa Dusseault, "YOUR NAME HERE" -- send comments to drinks list. Mule, et al. Expires September 9, 2010 [Page 46] Internet-Draft draft-mule-drinks-proto March 2010 14. References 14.1. Normative References [I-D.cartwright-drinks-sppp-over-soap] Cartwright, K., "SPPP Over SOAP and HTTP", draft-cartwright-drinks-sppp-over-soap-00 (work in progress), February 2010. [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. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [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. 14.2. Informative References [I-D.ietf-drinks-usecases-requirements] Channabasappa, S., "DRINKS Use cases and Protocol Requirements", draft-ietf-drinks-usecases-requirements-00 (work in progress), May 2009. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [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 System (DDDS) Application (ENUM)", RFC 3761, April 2004. [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation Architecture", RFC 4725, November 2006. [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, Mule, et al. Expires September 9, 2010 [Page 47] Internet-Draft draft-mule-drinks-proto March 2010 March 2009. Mule, et al. Expires September 9, 2010 [Page 48] Internet-Draft draft-mule-drinks-proto March 2010 Authors' Addresses Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: jfm@cablelabs.com Kenneth Cartwright TNS 1939 Roland Clarke Place Reston, VA 20191 USA Email: kcartwright@tnsi.com Syed Wasim Ali NeuStar USA Email: syed.ali@neustar.biz Alexander Mayrhofer enum.at GmbH Karlsplatz 1/9 Wien, A-1010 Austria Email: alexander.mayrhofer@enum.at Debbie Guyton Telcordia Technologies 1 Telcordia Drive/RRC 1E222 Piscataway, NJ 08854 USA Email: dguyton@telcordia.com Mule, et al. Expires September 9, 2010 [Page 49]