draft-ietf-drinks-spp-framework-09.txt   draft-ietf-drinks-spp-framework-10.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 25, 2015 S. Ali Expires: September 26, 2015 S. Ali
NeuStar NeuStar
D. Schwartz D. Schwartz
XConnect XConnect
October 22, 2014 March 25, 2015
Session Peering Provisioning Framework (SPPF) Session Peering Provisioning Framework (SPPF)
draft-ietf-drinks-spp-framework-09 draft-ietf-drinks-spp-framework-10
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 25, 2015. This Internet-Draft will expire on September 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 10, line 50 skipping to change at page 10, line 50
timezone digits. timezone digits.
"2010-05-30T09:30:10Z" is an example of an acceptable time value for "2010-05-30T09:30:10Z" is an example of an acceptable time value for
use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC
time, but it is not approved for use in SPPF messages. time, but it is not approved for use in SPPF messages.
3.3. Extensibility 3.3. Extensibility
The framework contains various points of extensibility in form of the The framework contains various points of extensibility in form of the
"ext" elements. Extensions used beyond the scope of private SPPF "ext" elements. Extensions used beyond the scope of private SPPF
installations MUST be documented in an RFC level document, and the installations MUST be documented in an RFC, and the first such
first such extension SHOULD define an IANA registry, holding a list extension SHOULD define an IANA registry, holding a list of
of documented extensions. documented extensions.
4. Transport Protocol Requirements 4. Transport Protocol Requirements
This section provides requirements for transport protocols suitable This section provides requirements for transport protocols suitable
for SPPF. More specifically, this section specifies the services, for SPPF. More specifically, this section specifies the services,
features, and assumptions that SPPF framework delegates to the chosen features, and assumptions that SPPF framework delegates to the chosen
transport and envelope technologies. transport and envelope technologies.
4.1. Connection Oriented 4.1. Connection Oriented
skipping to change at page 14, line 33 skipping to change at page 14, line 33
has the object's name, object's type and its Registrant's has the object's name, object's type and its Registrant's
organization ID as its attributes. The abstract type called organization ID as its attributes. The abstract type called
ObjKeyType is where this unique identity is housed. Any concrete ObjKeyType is where this unique identity is housed. Any concrete
representation of the ObjKeyType MUST contain the following: representation of the ObjKeyType MUST contain the following:
Object Name: The name of the object. Object Name: The name of the object.
Registrant Id: The unique organization ID that identifies the Registrant Id: The unique organization ID that identifies the
Registrant. Registrant.
Type: The value that represents the type of SPPF object that. Type: The value that represents the type of SPPF object. This is
This is required as different types of objects in SPPF, that required as different types of objects in SPPF, that belong to the
belong to the same Registrant, can have the same name. same Registrant, can have the same name.
The structure of abstract ObjKeyType is as follows: The structure of abstract ObjKeyType is as follows:
<complexType name="ObjKeyType" abstract="true"> <complexType name="ObjKeyType" abstract="true">
<annotation> <annotation>
<documentation> <documentation>
---- Generic type that represents the ---- Generic type that represents the
key for various objects in SPPF. ---- key for various objects in SPPF. ----
</documentation> </documentation>
</annotation> </annotation>
skipping to change at page 15, line 41 skipping to change at page 15, line 41
<annotation> <annotation>
<documentation> <documentation>
---- Generic type that represents ---- Generic type that represents
the key for a object offer. ---- the key for a object offer. ----
</documentation> </documentation>
</annotation> </annotation>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
A SED Group Offer object MUST use SedGrpOfferKeyType. Refer the A SED Group Offer object MUST use SedGrpOfferKeyType. Refer to
"Framework Data Model Objects" section of this document for the "Framework Data Model Objects" section of this document for
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.
skipping to change at page 18, line 51 skipping to change at page 18, line 51
supported data model object (the nouns) and identifies the commands supported data model object (the nouns) and identifies the commands
(the verbs) that MUST be supported for each data model object. (the verbs) that MUST be supported for each data model object.
However, the specification of the data structures necessary to However, the specification of the data structures necessary to
support each command is delegated to an SPPF conforming transport support each command is delegated to an SPPF conforming transport
protocol specification. protocol specification.
6.1. Destination Group 6.1. Destination Group
Destination Group represents a logical grouping of Public Identifiers Destination Group represents a logical grouping of Public Identifiers
with common session establishment information. The transport with common session establishment information. The transport
protocol MUST support the ability to Create, Modify, Get, and Delete protocol MUST support the ability to Add, Get, and Delete Destination
Destination Groups (refer the "Framework Operations" section of this Groups (refer to the "Framework Operations" section of this document
document for a generic description of various operations). for a generic description of various operations).
A Destination Group object MUST be uniquely identified by attributes A Destination Group object MUST be uniquely identified by attributes
as defined in the description of "ObjKeyType" in the section "Generic as defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document. Object Key Type" of this document.
The DestGrpType object structure is defined as follows: The DestGrpType object structure is defined as follows:
<complexType name="DestGrpType"> <complexType name="DestGrpType">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
skipping to change at page 19, line 46 skipping to change at page 19, line 46
establishment data (SED). In many cases, a Public Identifier is establishment data (SED). In many cases, a Public Identifier is
attributed to the end user who has a retail relationship with the attributed to the end user who has a retail relationship with the
service provider or Registrant organization. SPPF supports the service provider or Registrant organization. SPPF supports the
notion of the carrier-of-record as defined in [RFC5067]. Therefore, notion of the carrier-of-record as defined in [RFC5067]. Therefore,
the Registrant under whom the Public Identity is being created can the Registrant under whom the Public Identity is being created can
optionally claim to be a carrier-of-record. optionally claim to be a carrier-of-record.
SPPF identifies three types of Public Identifiers: telephone numbers SPPF identifies three types of Public Identifiers: telephone numbers
(TN), routing numbers (RN), and URI. SPPF provides structures to (TN), routing numbers (RN), and URI. SPPF provides structures to
manage a single TN, a contiguous range of TNs, and a TN prefix. The manage a single TN, a contiguous range of TNs, and a TN prefix. The
transport protocol MUST support the ability to Create, Modify, Get, transport protocol MUST support the ability to Add, Get, and Delete
and Delete Public Identifiers (refer the "Framework Operations" Public Identifiers (refer to the "Framework Operations" section of
section of this document for a generic description of various this document for a generic description of various operations).
operations).
A Public Identity object MUST be uniquely identified by attributes as A Public Identity object MUST be uniquely identified by attributes as
defined in the description of "PubIdKeyType" in the section defined in the description of "PubIdKeyType" in the section
Section 5.2.2. Section 5.2.2.
The abstract XML schema type definition PubIdType is a generalization The abstract XML schema type definition PubIdType is a generalization
for the concrete Public Identifier schema types. PubIdType element for the concrete Public Identifier schema types. PubIdType element
'dgName' represents the name of a destination group that a given 'dgName' represents the name of a destination group that a given
Public Identifier may be a member of. Note that this element may be Public Identifier may be a member of. Note that this element may be
present multiple times so that a given Public Identifier may be a present multiple times so that a given Public Identifier may be a
skipping to change at page 25, line 9 skipping to change at page 25, line 9
SED Group is a grouping of one or more Destination Group, the common SED Group is a grouping of one or more Destination Group, the common
SED Records, and the list of peer organizations with access to the SED Records, and the list of peer organizations with access to the
SED Records associated with a given SED Group. It is this indirect SED Records associated with a given SED Group. It is this indirect
linking of public identifiers to their Session Establishment Data linking of public identifiers to their Session Establishment Data
that significantly improves the scalability and manageability of the that significantly improves the scalability and manageability of the
peering data. Additions and changes to SED information are reduced peering data. Additions and changes to SED information are reduced
to a single operation on a SED Group or SED Record , rather than to a single operation on a SED Group or SED Record , rather than
millions of data updates to individual public identifier records that millions of data updates to individual public identifier records that
individually contain their peering data. The transport protocol MUST individually contain their peering data. The transport protocol MUST
support the ability to Create, Modify, Get, and Delete SED Groups support the ability to Add, Get, and Delete SED Groups (refer to the
(refer the "Framework Operations" section of this document for a "Framework Operations" section of this document for a generic
generic description of various operations). description of various operations).
A SED Group object MUST be uniquely identified by attributes as A SED Group object MUST be uniquely identified by attributes as
defined in the description of "ObjKeyType" in the section "Generic defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document. Object Key Type" of this document.
The SedGrpType object structure is defined as follows: The SedGrpType object structure is defined as follows:
<complexType name="SedGrpType"> <complexType name="SedGrpType">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
skipping to change at page 28, line 25 skipping to change at page 28, line 25
6.4. SED Record 6.4. SED Record
SED Group represents a combined grouping of SED Records that define SED Group represents a combined grouping of SED Records that define
session establishment information. However, SED Records need not be session establishment information. However, SED Records need not be
created to just serve a single SED Group. SED Records can be created created to just serve a single SED Group. SED Records can be created
and managed to serve multiple SED Groups. As a result, a change for and managed to serve multiple SED Groups. As a result, a change for
example to the properties of a network node used for multiple routes, example to the properties of a network node used for multiple routes,
would necessitate just a single update operation to change the would necessitate just a single update operation to change the
properties of that node. The change would then be reflected in all properties of that node. The change would then be reflected in all
the SED Groups whose SED record set contains a reference to that the SED Groups whose SED record set contains a reference to that
node. The transport protocol MUST support the ability to Create, node. The transport protocol MUST support the ability to Add, Get,
Modify, Get, and Delete SED Records (refer the "Framework Operations" and Delete SED Records (refer to the "Framework Operations" section
section of this document for a generic description of various of this document for a generic description of various operations).
operations).
A SED Record object MUST be uniquely identified by attributes as A SED Record object MUST be uniquely identified by attributes as
defined in the description of "ObjKeyType" in the section "Generic defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document. Object Key Type" of this document.
The SedRecType object structure is defined as follows: The SedRecType object structure is defined as follows:
<complexType name="SedRecType" abstract="true"> <complexType name="SedRecType" abstract="true">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
skipping to change at page 32, line 47 skipping to change at page 32, line 47
is controlled by the organization to which a SED Group object belongs is controlled by the organization to which a SED Group object belongs
(its Registrant), and the peer organization that submits resolution (its Registrant), and the peer organization that submits resolution
requests (a data recipient, also know as a peering organization). requests (a data recipient, also know as a peering organization).
The Registrant offers access to a SED Group by submitting a SED Group The Registrant offers access to a SED Group by submitting a SED Group
Offer. The data recipient can then accept or reject that offer. Not Offer. The data recipient can then accept or reject that offer. Not
until access to a SED Group has been offered and accepted will the until access to a SED Group has been offered and accepted will the
data recipient's organization ID be included in the peeringOrg list data recipient's organization ID be included in the peeringOrg list
in a SED Group object, and that SED Group's peering information in a SED Group object, and that SED Group's peering information
become a candidate for inclusion in the responses to the resolution become a candidate for inclusion in the responses to the resolution
requests submitted by that data recipient. The transport protocol requests submitted by that data recipient. The transport protocol
MUST support the ability to Create, Modify, Get, Delete, Accept and MUST support the ability to Add, Get, Delete, Accept and Reject SED
Reject SED Group Offers (refer the "Framework Operations" section of Group Offers (refer to the "Framework Operations" section of this
this document for a generic description of various operations). document for a generic description of various operations).
A SED Group Offer object MUST be uniquely identified by attributes as A SED Group Offer object MUST be uniquely identified by attributes as
defined in the description of "SedGrpOfferKeyType" in the section defined in the description of "SedGrpOfferKeyType" in the section
"Derived Object Key Types" of this document. "Derived Object Key Types" of this document.
The SedGrpOfferType object structure is defined as follows: The SedGrpOfferType object structure is defined as follows:
<complexType name="SedGrpOfferType"> <complexType name="SedGrpOfferType">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
skipping to change at page 34, line 36 skipping to change at page 34, line 36
establishment data, to share one or more ingress routes and that the establishment data, to share one or more ingress routes and that the
originating SSP has accepted the offer. In order to add the egress originating SSP has accepted the offer. In order to add the egress
route to the Registry, the originating SSP uses a valid regular route to the Registry, the originating SSP uses a valid regular
expression to rewrite ingress route in order to include the egress expression to rewrite ingress route in order to include the egress
SBE information. Also, more than one egress route can be associated SBE information. Also, more than one egress route can be associated
with a given ingress route in support of fault-tolerant with a given ingress route in support of fault-tolerant
configurations. The supporting SPPF structure provides a way to configurations. The supporting SPPF structure provides a way to
include route precedence information to help manage traffic to more include route precedence information to help manage traffic to more
than one outbound egress SBE. than one outbound egress SBE.
The transport protocol MUST support the ability to Add, Modify, Get, The transport protocol MUST support the ability to Add, Get, and
and Delete Egress Routes (refer the "Framework Operations" section of Delete Egress Routes (refer to the "Framework Operations" section of
this document for a generic description of various operations). The this document for a generic description of various operations). The
EgrRteType object structure is defined as follows: EgrRteType object structure is defined as follows:
<complexType name="EgrRteType"> <complexType name="EgrRteType">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
<sequence> <sequence>
<element name="egrRteName" type="sppfb:ObjNameType"/> <element name="egrRteName" type="sppfb:ObjNameType"/>
<element name="pref" type="unsignedShort"/> <element name="pref" type="unsignedShort"/>
<element name="regxRewriteRule" type="sppfb:RegexParamType"/> <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
skipping to change at page 36, line 27 skipping to change at page 36, line 27
7.1. Add Operation 7.1. Add Operation
Any conforming transport protocol specification MUST provide a Any conforming transport protocol specification MUST provide a
definition for the operation that adds one or more SPPF objects into definition for the operation that adds one or more SPPF objects into
the Registry. If the object, as identified by the request attributes the Registry. If the object, as identified by the request attributes
that form part of the object's key, does not exist, then the Registry that form part of the object's key, does not exist, then the Registry
MUST create the object. If the object does exist, then the Registry MUST create the object. If the object does exist, then the Registry
MUST replace the current properties of the object with the properties MUST replace the current properties of the object with the properties
passed in as part of the Add operation. passed in as part of the Add operation.
Note that this effectively allows to modify a pre-existing object.
If the entity that issued the command is not authorized to perform If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types" amongst the response messages defined in "Response Message Types"
section of the document. section of the document.
7.2. Delete Operation 7.2. Delete Operation
Any conforming transport protocol specification MUST provide a Any conforming transport protocol specification MUST provide a
definition for the operation that deletes one or more SPPF objects definition for the operation that deletes one or more SPPF objects
from the Registry using the object's key. from the Registry using the object's key.
 End of changes. 15 change blocks. 
32 lines changed or deleted 32 lines changed or added

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