draft-ietf-drinks-spp-framework-06.txt   draft-ietf-drinks-spp-framework-07.txt 
DRINKS K. Cartwright DRINKS K. Cartwright
Internet-Draft V. Bhatia Internet-Draft V. Bhatia
Intended status: Standards Track TNS Intended status: Standards Track TNS
Expires: April 24, 2014 S. Ali Expires: October 24, 2014 S. Ali
NeuStar NeuStar
D. Schwartz D. Schwartz
XConnect XConnect
October 21, 2013 April 22, 2014
Session Peering Provisioning Framework (SPPF) Session Peering Provisioning Framework (SPPF)
draft-ietf-drinks-spp-framework-06 draft-ietf-drinks-spp-framework-07
Abstract Abstract
This document specifies the data model and the overall structure for This document specifies the data model and the overall structure for
a framework to provision session establishment data into Session Data a framework to provision session establishment data into Session Data
Registries and SIP Service Provider data stores. The framework is Registries and SIP Service Provider data stores. The framework is
called the Session Peering Provisioning Framework (SPPF). The called the Session Peering Provisioning Framework (SPPF). The
provisioned data is typically used by network elements for session provisioned data is typically used by network elements for session
establishment. establishment.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014. This Internet-Draft will expire on October 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Framework High Level Design . . . . . . . . . . . . . . . . . 7 3. Framework High Level Design . . . . . . . . . . . . . . . . . 7
3.1. Framework Data Model . . . . . . . . . . . . . . . . . . 7 3.1. Framework Data Model . . . . . . . . . . . . . . . . . . 7
3.2. Time Value . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Time Value . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
4. Transport Protocol Requirements . . . . . . . . . . . . . . . 11 4. Transport Protocol Requirements . . . . . . . . . . . . . . . 11
4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 11 4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 11
4.2. Request and Response Model . . . . . . . . . . . . . . . 11 4.2. Request and Response Model . . . . . . . . . . . . . . . 11
4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 11 4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 11
4.4. Authentication . . . . . . . . . . . . . . . . . . . . . 11 4.4. Authentication . . . . . . . . . . . . . . . . . . . . . 11
4.5. Authorization . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Confidentiality and Integrity . . . . . . . . . . . . . . 12 4.6. Confidentiality and Integrity . . . . . . . . . . . . . . 12
4.7. Near Real Time . . . . . . . . . . . . . . . . . . . . . 12 4.7. Near Real Time . . . . . . . . . . . . . . . . . . . . . 12
4.8. Request and Response Sizes . . . . . . . . . . . . . . . 12 4.8. Request and Response Sizes . . . . . . . . . . . . . . . 12
4.9. Request and Response Correlation . . . . . . . . . . . . 12 4.9. Request and Response Correlation . . . . . . . . . . . . 12
4.10. Request Acknowledgement . . . . . . . . . . . . . . . . . 12 4.10. Request Acknowledgement . . . . . . . . . . . . . . . . . 12
4.11. Mandatory Transport . . . . . . . . . . . . . . . . . . . 13 4.11. Mandatory Transport . . . . . . . . . . . . . . . . . . . 13
5. Base Framework Data Structures and Response Codes . . . . . . 13 5. Base Framework Data Structures and Response Codes . . . . . . 13
5.1. Basic Object Type and Organization Identifiers . . . . . 13 5.1. Basic Object Type and Organization Identifiers . . . . . 13
5.2. Various Object Key Types . . . . . . . . . . . . . . . . 13 5.2. Various Object Key Types . . . . . . . . . . . . . . . . 14
5.2.1. Generic Object Key Type . . . . . . . . . . . . . . . 14 5.2.1. Generic Object Key Type . . . . . . . . . . . . . . . 14
5.2.2. Derived Object Key Types . . . . . . . . . . . . . . 15 5.2.2. Derived Object Key Types . . . . . . . . . . . . . . 15
5.3. Response Message Types . . . . . . . . . . . . . . . . . 16 5.3. Response Message Types . . . . . . . . . . . . . . . . . 16
6. Framework Data Model Objects . . . . . . . . . . . . . . . . 18 6. Framework Data Model Objects . . . . . . . . . . . . . . . . 18
6.1. Destination Group . . . . . . . . . . . . . . . . . . . . 19 6.1. Destination Group . . . . . . . . . . . . . . . . . . . . 18
6.2. Public Identifier . . . . . . . . . . . . . . . . . . . . 19 6.2. Public Identifier . . . . . . . . . . . . . . . . . . . . 19
6.3. SED Group . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. SED Group . . . . . . . . . . . . . . . . . . . . . . . . 24
6.4. SED Record . . . . . . . . . . . . . . . . . . . . . . . 28 6.4. SED Record . . . . . . . . . . . . . . . . . . . . . . . 28
6.5. SED Group Offer . . . . . . . . . . . . . . . . . . . . . 32 6.5. SED Group Offer . . . . . . . . . . . . . . . . . . . . . 32
6.6. Egress Route . . . . . . . . . . . . . . . . . . . . . . 33 6.6. Egress Route . . . . . . . . . . . . . . . . . . . . . . 34
7. Framework Operations . . . . . . . . . . . . . . . . . . . . 35 7. Framework Operations . . . . . . . . . . . . . . . . . . . . 36
7.1. Add Operation . . . . . . . . . . . . . . . . . . . . . . 35 7.1. Add Operation . . . . . . . . . . . . . . . . . . . . . . 36
7.2. Delete Operation . . . . . . . . . . . . . . . . . . . . 35 7.2. Delete Operation . . . . . . . . . . . . . . . . . . . . 36
7.3. Get Operations . . . . . . . . . . . . . . . . . . . . . 36 7.3. Get Operations . . . . . . . . . . . . . . . . . . . . . 37
7.4. Accept Operations . . . . . . . . . . . . . . . . . . . . 37 7.4. Accept Operations . . . . . . . . . . . . . . . . . . . . 38
7.5. Reject Operations . . . . . . . . . . . . . . . . . . . . 37 7.5. Reject Operations . . . . . . . . . . . . . . . . . . . . 38
7.6. Get Server Details Operation . . . . . . . . . . . . . . 38 7.6. Get Server Details Operation . . . . . . . . . . . . . . 39
8. XML Considerations . . . . . . . . . . . . . . . . . . . . . 38 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . 39
8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 39
8.2. Versioning and Character Encoding . . . . . . . . . . . . 39 8.2. Versioning and Character Encoding . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9.1. Confidentiality and Authentication . . . . . . . . . . . 39 9.1. Confidentiality and Authentication . . . . . . . . . . . 40
9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 39 9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 40
9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40
9.3.1. DoS Issues Inherited from Transport Mechanism . . . . 40 9.3.1. DoS Issues Inherited from Transport Mechanism . . . . 41
9.3.2. DoS Issues Specific to SPPF . . . . . . . . . . . . . 41 9.3.2. DoS Issues Specific to SPPF . . . . . . . . . . . . . 41
9.4. Information Disclosure . . . . . . . . . . . . . . . . . 41 9.4. Information Disclosure . . . . . . . . . . . . . . . . . 42
9.5. Non Repudiation . . . . . . . . . . . . . . . . . . . . . 42 9.5. Non Repudiation . . . . . . . . . . . . . . . . . . . . . 42
9.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 42 9.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 42
9.7. Man in the Middle . . . . . . . . . . . . . . . . . . . . 42 9.7. Man in the Middle . . . . . . . . . . . . . . . . . . . . 43
10. Internationalization Considerations . . . . . . . . . . . . . 42 10. Internationalization Considerations . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43 11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43
11.2. Organization Identifier Namespace Registry . . . . . . . 43 11.2. Organization Identifier Namespace Registry . . . . . . . 44
12. Formal Specification . . . . . . . . . . . . . . . . . . . . 43 12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
14.1. Normative References . . . . . . . . . . . . . . . . . . 52 14.1. Normative References . . . . . . . . . . . . . . . . . . 53
14.2. Informative References . . . . . . . . . . . . . . . . . 53 14.2. Informative References . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
Service providers and enterprises use routing databases known as Service providers and enterprises use routing databases known as
registries to make session routing decisions for Voice over IP, SMS registries to make session routing decisions for Voice over IP, SMS
and MMS traffic exchanges. This document is narrowly focused on the and MMS traffic exchanges. This document is narrowly focused on the
provisioning framework for these registries. This framework provisioning framework for these registries. This framework
prescribes a way for an entity to provision session-related data into prescribes a way for an entity to provision session-related data into
a Registry. The data being provisioned can be optionally shared with a Registry. The data being provisioned can be optionally shared with
other participating peering entities. The requirements and use cases other participating peering entities. The requirements and use cases
skipping to change at page 16, line 5 skipping to change at page 16, line 4
description of SED Group Offer object. description of SED Group Offer object.
o PubIdKeyType: This uniquely identifies a Public Identity object. o PubIdKeyType: This uniquely identifies a Public Identity object.
This key type extends from abstract ObjKeyType. Any concrete This key type extends from abstract ObjKeyType. Any concrete
definition of PubIdKeyType MUST contain the elements that identify definition of PubIdKeyType MUST contain the elements that identify
the value and type of Public Identity and also contain the the value and type of Public Identity and also contain the
organization ID of the Registrant that is the owner of the Public organization ID of the Registrant that is the owner of the Public
Identity object. A Public Identity object in SPPF is uniquely Identity object. A Public Identity object in SPPF is uniquely
identified by the Registrant's organization ID, the value of the identified by the Registrant's organization ID, the value of the
public identity, and the type of the public identity object. public identity, and the type of the public identity object.
Consequently, any concrete representation of the PubIdKeyType MUST Consequently, any concrete representation of the PubIdKeyType MUST
contain the following attributes: contain the following attributes:
Registrant Id: The unique organization ID that identifies the * Registrant Id: The unique organization ID that identifies the
Registrant. Registrant.
Value: The value of the Public Identity. * Value: The value of the Public Identity.
Type: The type of the Public Identity Object. * Type: The type of the Public Identity Object.
The PubIdKeyType is used in Delete and Get operations on a Public The PubIdKeyType is used in Delete and Get operations on a Public
Identifier object. Identifier object.
o The structure of abstract PubIdKeyType is as follows: o The structure of abstract PubIdKeyType is as follows:
<complexType name="PubIdKeyType" abstract="true"> <complexType name="PubIdKeyType" abstract="true">
<complexContent> <complexContent>
<extension base="sppfb:ObjKeyType"> <extension base="sppfb:ObjKeyType">
<annotation> <annotation>
skipping to change at page 16, line 42 skipping to change at page 16, line 42
A Public Identity object MUST use attributes of PubIdKeyType for its A Public Identity object MUST use attributes of PubIdKeyType for its
unique identification . Refer to Section 6 for a description of unique identification . Refer to Section 6 for a description of
Public Identity object. Public Identity object.
5.3. Response Message Types 5.3. Response Message Types
This section contains the listing of response types that MUST be This section contains the listing of response types that MUST be
defined by the SPPF conforming transport protocol specification and defined by the SPPF conforming transport protocol specification and
implemented by a conforming SPPF server. implemented by a conforming SPPF server.
+-----------------+-------------------------------------------------+ +---------------------+---------------------------------------------+
| Response Type | Description | | Response Type | Description |
+-----------------+-------------------------------------------------+ +---------------------+---------------------------------------------+
| Request | Any conforming specification MUST define a | | Request Succeeded | Any conforming specification MUST define a |
| Succeeded | response to indicate that a given request | | | response to indicate that a given request |
| | succeeded. | | | succeeded. |
| | | | | |
| Request syntax | Any conforming specification MUST define a | | Request syntax | Any conforming specification MUST define a |
| invalid | response to indicate that a syntax of a given | | invalid | response to indicate that a syntax of a |
| | request was found invalid. | | | given request was found invalid. |
| | | | | |
| Request too | Any conforming specification MUST define a | | Request too large | Any conforming specification MUST define a |
| large | response to indicate that the count of entities | | | response to indicate that the count of |
| | in the request is larger than the server is | | | entities in the request is larger than the |
| | willing or able to process. | | | server is willing or able to process. |
| | | | | |
| Version not | Any conforming specification MUST define a | | Version not | Any conforming specification MUST define a |
| supported | response to indicate that the server does not | | supported | response to indicate that the server does |
| | support the version of the SPPF protocol | | | not support the version of the SPPF |
| | specified in the request. | | | protocol specified in the request. |
| | | | | |
| Command invalid | Any conforming specification MUST define a | | Command invalid | Any conforming specification MUST define a |
| | response to indicate that the operation and/or | | | response to indicate that the operation |
| | command being requested by the client is | | | and/or command being requested by the |
| | invalid and/or not supported by the server. | | | client is invalid and/or not supported by |
| | | | | the server. |
| System | Any conforming specification MUST define a | | | |
| temporarily | response to indicate that the SPPF server is | | System temporarily | Any conforming specification MUST define a |
| unavailable | temporarily not available to serve client | | unavailable | response to indicate that the SPPF server |
| | request. | | | is temporarily not available to serve |
| | | | | client request. |
| Unexpected | Any conforming specification MUST define a | | | |
| internal system | response to indicate that the SPPF server | | Unexpected internal | Any conforming specification MUST define a |
| or server | encountered an unexpected error that prevented | | system or server | response to indicate that the SPPF server |
| error. | the server from fulfilling the request. | | error. | encountered an unexpected error that |
| | | | | prevented the server from fulfilling the |
| Attribute value | Any conforming specification MUST define a | | | request. |
| invalid | response to indicate that the SPPF server | | | |
| | encountered an attribute or property in the | | Attribute value | Any conforming specification MUST define a |
| | request that had an invalid/bad value. | | invalid | response to indicate that the SPPF server |
| | Optionally, the specification MAY provide a way | | | encountered an attribute or property in the |
| | to indicate the Attribute Name and the | | | request that had an invalid/bad value. |
| | Attribute Value to identify the object that was | | | Optionally, the specification MAY provide a |
| | found to be invalid. | | | way to indicate the Attribute Name and the |
| | | | | Attribute Value to identify the object that |
| Object does not | Any conforming specification MUST define a | | | was found to be invalid. |
| exist | response to indicate that an object present in | | | |
| | the request does not exist on the SPPF server. | | Object does not | Any conforming specification MUST define a |
| | Optionally, the specification MAY provide a way | | exist | response to indicate that an object present |
| | to indicate the Attribute Name and the | | | in the request does not exist on the SPPF |
| | Attribute Value that identifies the non- | | | server. Optionally, the specification MAY |
| | existent object. | | | provide a way to indicate the Attribute |
| | | | | Name and the Attribute Value that |
| Object status | Any conforming specification MUST define a | | | identifies the non-existent object. |
| or ownership | response to indicate that the operation | | | |
| does not allow | requested on an object present in the request | | Object status or | Any conforming specification MUST define a |
| for operation. | cannot be performed because the object is in a | | ownership does not | response to indicate that the operation |
| | status that does not allow the said operation | | allow for | requested on an object present in the |
| | or the user requesting the operation is not | | operation. | request cannot be performed because the |
| | authorized to perform the said operation on the | | | object is in a status that does not allow |
| | object. Optionally, the specification MAY | | | the said operation or the user requesting |
| | provide a way to indicate the Attribute Name | | | the operation is not authorized to perform |
| | and the Attribute Value that identifies the | | | the said operation on the object. |
| | object. | | | Optionally, the specification MAY provide a |
+-----------------+-------------------------------------------------+ | | way to indicate the Attribute Name and the |
| | Attribute Value that identifies the object. |
+---------------------+---------------------------------------------+
Table 1: Response Types Table 1: Response Types
When the response messages are "parameterized" with the Attribute When the response messages are "parameterized" with the Attribute
Name and Attribute Value, then the use of these parameters MUST Name and Attribute Value, then the use of these parameters MUST
adhere to the following rules: adhere to the following rules:
o Any value provided for the Attribute Name parameter MUST be an o Any value provided for the Attribute Name parameter MUST be an
exact XSD element name of the protocol data element that the exact XSD element name of the protocol data element that the
response message is referring to. For example, valid values for response message is referring to. For example, valid values for
skipping to change at page 43, line 32 skipping to change at page 44, line 12
XML: See the "Formal Specification" section of this document XML: See the "Formal Specification" section of this document
(Section 12). (Section 12).
11.2. Organization Identifier Namespace Registry 11.2. Organization Identifier Namespace Registry
IANA is requested to create and maintain a Registry entitled "SPPF IANA is requested to create and maintain a Registry entitled "SPPF
OrgIdType Namespaces". Strings used as OrgIdType Namespace OrgIdType Namespaces". Strings used as OrgIdType Namespace
identifiers MUST conform to the following syntax in the Augmented identifiers MUST conform to the following syntax in the Augmented
Backus-Naur Form (ABNF) [RFC5234] Backus-Naur Form (ABNF) [RFC5234]
namespace = ALPHA * (ALPHA/DIGIT/"-") namespace = ALPHA * (ALPHA/DIGIT/"-")
Assignments consist of the OrgIdType namespace string, and the Assignments consist of the OrgIdType namespace string, and the
definition of the associated namespace. This document makes the definition of the associated namespace. This document makes the
following initial assignment for the OrgIdType Namespaces: following initial assignment for the OrgIdType Namespaces:
OrgIdType namespace string Namespace OrgIdType namespace string Namespace
-------------------------- --------- -------------------------- ---------
IANA Enterprise Numbers iana-en IANA Enterprise Numbers iana-en
Future assignments are to be made through the well known IANA Policy Future assignments are to be made through the well known IANA Policy
"RFC Required" (see section 4.1 of [RFC5226]) "RFC Required" (see section 4.1 of [RFC5226])
12. Formal Specification 12. Formal Specification
This section provides the draft XML Schema Definition for SPPF This section provides the draft XML Schema Definition for SPPF
Protocol. Protocol.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 53, line 36 skipping to change at page 54, line 21
Part Three: The Domain Name System (DNS) Database", RFC Part Three: The Domain Name System (DNS) Database", RFC
3403, October 2002. 3403, October 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004. System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
Architecture", RFC 4725, November 2006. Architecture", RFC 4725, November 2006.
[RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of- [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006. Service Considerations", RFC 4732, December 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486, March Interconnect (SPEERMINT) Terminology", RFC 5486, March
 End of changes. 24 change blocks. 
103 lines changed or deleted 106 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/