One document matched: draft-ietf-drinks-usecases-requirements-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3261 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3263 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml">
<!ENTITY rfc3761 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml">
<!ENTITY rfc5486 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5486.xml">
]>
<rfc category="info" docName="draft-ietf-drinks-usecases-requirements-02" ipr="trust200811">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="ietf-drinks-usecases-reqs">
DRINKS Use cases and Protocol Requirements
</title>
<author initials='S.' surname="Channabasappa, Ed." fullname='Sumanth Channabasappa'>
<organization>CableLabs </organization>
<address>
<postal>
<street>858 Coal Creek Circle</street>
<city>Louisville</city> <region>CO</region>
<code>80027</code>
<country>USA</country>
</postal>
<email>sumanth@cablelabs.com</email>
</address>
</author>
<date year="2010" month="May"/>
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>DRINKS</workgroup>
<abstract>
<t>
This document captures the use cases and associated requirements for interfaces that provision session establishment data into SIP Service Provider components, to assist with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry.
</t>
</abstract>
</front>
<middle>
<section anchor="Terminology" title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
<t>
This document reuses terms from <xref target="RFC3261"/> (e.g., SIP) and <xref target="RFC5486"/> (e.g., LUF, LRF). In addition, this document specifies the following additional terms.
<vspace blankLines='1'/>
<list style="hanging">
<t hangText="Registry: ">
The authoritative source for provisioned session establishment data (SED) and related information.
<vspace blankLines='2' />
</t>
<t hangText="Local Data Repository: ">
The data store component of an addressing server that provides resolution responses.
<vspace blankLines='2' />
</t>
<t hangText="Destination Group: ">
A set of public identities that are grouped together to facilitate session setup and routing.
<vspace blankLines='2' />
</t>
<t hangText="Public Identity: ">
A generic term that refers to a telephone number (TN), an email address, or other identity as deemed appropriate, such as a globally routable URI of a user address (e.g., mailto:john.doe@example.net).
<vspace blankLines='2' />
</t>
<t hangText="Routing Group: ">
A grouping of SED records.
<vspace blankLines='2' />
</t>
<t hangText="Authoritative SSP or Entity">
This refers to the carrier-of-record, for a public identity or TN Range.
</t>
<t hangText="Non-authoritative SSP or Entity">
This refers to the transit provider for a public identity or TN Range.
</t>
<!--
<t hangText="SED Record: ">
A SED Record contains much of the session establishment data or a 'redirect' to another registry where the session establishment data can be discovered. SED Records types supported are NAPTRs, CNAME, DNAME, and NS Records.
<vspace blankLines='1' />
<vspace blankLines='2' />
</t>
<t hangText="Data Recipient: ">
SP or SSP that receives or consumes SED and related information.
<vspace blankLines='2' />
</t>
<t hangText="Data Recipient Group: ">
A group of Data Recipients that receive the same set (or subset) of SED and related information.
<vspace blankLines='2' />
</t>
-->
</list>
</t>
</section>
<section anchor="Overview" title="Overview">
<t>
The SPEERMINT WG specifies Session Establishment Data, or SED, as the data used to route a call to the next hop associated with the called domain's ingress point. More specifically, the SED is the set of parameters that the outgoing signalling path border elements (SBEs) need to establish a session. See <xref target="RFC5486"/> for more details.
<vspace blankLines='1' />
The specification of the format and protocols to provision SED is a task taken up by the DRINKS WG. The use cases and requirements that have been proposed in this regard are compiled in this document.
<vspace blankLines='1' />
SED is typically created by the terminating SSP and consumed by the originating SSP. To avoid a multitude of bilateral exchanges, SED is usually shared via intermediary systems - termed Registries within this document. Such registries receive SED via provisioning transactions from other SSPs, and then distribute the received data into Local Data Repositories. These local data repositories are used for call routing by outgoing SBEs. This is depicted in <xref target="GeneralOverview"/>.
<vspace blankLines='1' />
<figure title="General Diagram" anchor="GeneralOverview">
<artwork>
<![CDATA[
*-------------*
1. Provision SED | |
-----------------------> | Registry |
| |
*-------------*
/ \
/ \
/ \
/ \
/ \
/ \
/ 2.Distribute \
/ SED \
V V
+----------+ +----------+
|Local Data| |Local Data|
|Repository| |Repository|
+----------+ +----------+
]]>
</artwork>
</figure>
<vspace blankLines='1' />
In this version of the document, we primarily address the use cases and requirements for provisioning registries. Future revisions may include data distribution. The resulting provisioning protocol can be used to provision data into a registry, or between registries. This is depicted in <xref target="FunctionalOverview"/>.
<vspace blankLines='1' />
<figure title="Functional Overview" anchor="FunctionalOverview">
<artwork>
<![CDATA[
. . . . . . .
. . . . . . . registry . . . . . . .
. . . . . . . . .
. . .
. . provision .
+-----------+ . +-----------+
| | provision +----------+ provision | |
| SSP 1 |------------>| Registry |<-----------| SSP 2 |
| | +----------+ | |
| +-----+ | /\ | +-----+ |
| | LDR | <-------------------- ------------------>| LDR | |
| +-----+ | distribute distribute | +-----+ |
| | | |
+-----------+ +-----------+
. .
. . . . . . . . . . . . . . . . . . . . . . . .
(provision / distribute)
Where, LDR = Local Data Repository
]]>
</artwork>
</figure>
<vspace blankLines='1' />
The following is a summary of the proposed responsibilities for Registries and Local Data Repositories:
<list style="symbols">
<t>
Registries are the authoritative source for provisioned session establishment data (SED) and related information.
<vspace blankLines='1' />
</t>
<t>
Local Data Repositories are the data store component of an addressing server that provides resolution responses.
<vspace blankLines='1' />
</t>
<t>
Registries are responsible for distributing SED and related information to the local data repositories.
<vspace blankLines='1' />
</t>
</list>
<vspace blankLines='1' />
In addition, this document proposes the following aggregation groups with regards to SED (refer to the use cases in <xref target="CategoryDataAggregations"/> for the rationale):
<list style="symbols">
<t>
Aggregation of public Identifiers into a destination group.
<vspace blankLines='1' />
</t>
<!--
<t>
Aggregation of SSPs: It is expected that SSPs may want to expose different sets of SED, depending on the receiving SSP. This exposure may not always be unique, in which case an aggregation makes it efficient. Such an aggregation is proposed, and termed 'Data Receipient Group'.
<vspace blankLines='1' />
</t>
-->
<t>
Aggregation of SED records into a Routing Group.
<vspace blankLines='1' />
</t>
</list>
The above aggregations are illustrated in <xref target="DataModelDiagram"/>.
<vspace blankLines='1' />
<figure title="Data Model Diagram" anchor="DataModelDiagram">
<artwork>
<![CDATA[
+---------+ +--------------+ +---------+
| Data |0..n 1| ROUTING | 1 0..n| SED |
|Recepient|------------| GROUP | --------------| Record |
+---------+ +--------------+ +---------+
|0..n |0..n
| |
| |
| |
| 1 |
1..n +--------------+ 0..n |
---------| DESTINATION |--------- |
| | GROUP | | |
| +--------------+ | |
| | | |
| 1..n| | |
| | | |
| | | |
1 | 1 | | 1 |
+---------+ +---------+ +---------+ |
| RN | | TN | | Public |-----
| | | Range | |Identity | 1
+---------+ +---------+ +---------+
]]>
</artwork>
</figure>
<vspace blankLines='1' />
Additional clarifications follow:
<vspace blankLines='1' />
<list style='hanging'>
<t hangText="-">
A routing group is associated with zero or more SED Records; NAPTRs and other SED record types associated with routes are not user or TN-specific. For example the user portion of a NAPTR regular expression will be "\1".
<vspace blankLines='1' />
</t>
<t hangText="-">
A routing group is associated with zero or more peering organizations to control visibility or access privileges to that routing group and the destination groups they expose.
<vspace blankLines='1' />
</t>
<t hangText="-">
A data recipient group contains zero or more data recipients to facilitate the allocation of access privileges to routing groups.
</t>
</list>
</t>
</section>
<section anchor="UseCasesAndRequirements" title="Use Cases and Requirements">
<t>
This section presents the use cases and associated requirements.
</t>
<section anchor="RegistryProvisioning" title="Registry Provisioning">
<t>
This Section documents use cases related to the provisioning of the registry. Any request to provision, modify or delete data is subject to authorization. However, the act of authorization is considered out of scope within this document.
</t>
<section anchor="RegistryProvisioningUseCases" title="Use Cases">
<t>
The use cases are divided into the following categories - different provisioning options, options for provisioning SED data, administration, and number portability.
</t>
<section anchor="CategoryProcess" title="Category: Provisioning Options">
<t>
<list style='format UC PROCESS #%d'>
<t hangText="">
Real-time provisioning: once a registry is established events may occur that necessitate SSPs to add, modify or delete data in the registry, in real-time, to maintain accuracy of the data. Examples of such events can be found in other use cases within this document (e.g., identity related use cases).
<vspace blankLines='2' />
</t>
<t hangText="">
Non-real-time or bulk provisioning: There are cases when a registry needs to be provisioned with bulk data sets, via an offline mechanism, as opposed to real-time provisioning requests. Examples include: when a new registry is established or when data is being restored from a backup.
<vspace blankLines='2' />
</t>
</list>
</t>
</section>
<section anchor="CategoryRouting" title="Category: SED options">
<t>
<list style='format UC SED DATA #%d'>
<t hangText="">
Inter-network SED: An SSP provisons SED records for a specific end-user, so that other SSPs can use this SED data to establish sessions intended with this end-user. The provisioning SSP can either be the carrier-of-record (direct peering), or a transit provider (indirect peering).
<vspace blankLines='2' />
</t>
<t hangText="">
Intra-network SED: An SSP provisons SED records for a specific end-user, for use within the SSP's networks. This will allow internal signaling elements to establish sessions intended for this end-user. The provisioned SED is only distributed to specific local data repositories, and will probably differ from the SED provisioned for use by signaling elements from other SSPs.
<vspace blankLines='2' />
</t>
<t hangText="">
Selective peering: While an SSP may provision the same SED records for all other SSPs, an SSP may also wish to provision different SED records for different SSPs (e.g., if they have different peering agreements).
<vspace blankLines='2' />
</t>
<t hangText="">
LUF-only data: An SSP can choose to provison LUF-only data in the registry. A querying SSP that receives LUF-only data may need to rely on other mechanisms (e.g., <xref target="RFC3263"/> for domain-name based LUF) to obtain LRF information.
<vspace blankLines='2' />
</t>
<t hangText="">
LUF and LRF data: An SSP can provison LUF- and LRF-data in the registry. In such cases, the querying SSP does not have to rely on mechanisms such as DNS (e.g., <xref target="RFC3263"/>) for routing information.
<vspace blankLines='2' />
</t>
<t hangText="">
Target Domain as a resolvable Domain Name, administrative domain name, or both: The target domain pertaining to a public identity or TN Range can either be a DNS-resolvable domain name (i.e., via <xref target="RFC3263"/>) or an administrative domain. An SSP may also wish to provision both sets of data, and the response is based on a default choice or the querying entity.
<vspace blankLines='2' />
</t>
<t hangText="">
Target Domain as an administrative domain: The target domain for a public identity or TN Range can be an administrative domain. In such cases the resolution may be out of scope for this document.
<vspace blankLines='2' />
</t>
<t hangText="">
<vspace blankLines='2' />
</t>
<t hangText="">
EDITOR's NOTE: This use case seems to be a special case of LUF-only provisioning. Thoughts?
<vspace blankLines='2' />
Provision an authoritative name server: An SSP maintains a Tier 2 name server that contains the NAPTR records that constitute the terminal step in the LUF. The SSP needs to provision an registry to direct queries for the SSPs numbers to the Tier 2. Usually queries to the registry should return NS records, but, in cases where the Tier 2 uses a different domain suffix from that used in the registry, CNAME and NS records may be employed instead.
<vspace blankLines='2' />
</t>
</list>
</t>
</section>
<section anchor="CategoryDataAggregations" title="Category: Data Aggregations">
<t>
<list style='format UC DATA #%d'>
<t hangText="">
Aggregation of public Identifiers: The input key to a SED lookup is a public identifier. Since several public identifiers will potentially share similar (or identical) destinations, and hence similar (or identical) SED records, provisioning the same set of SED for millions of public identifiers is inefficient. Therefore, an aggregation mechanism to 'group' public identifiers is proposed. This aggregation is termed as a 'destination group' in the proposed data model.
<vspace blankLines='2' />
</t>
<t hangText="">
Aggregation of SED records: A complete set of session establishment data may consist of more than just one SED record. To be able to create and use the same set of SED records multiple times (without creating duplicates) an aggregation mechanism is required. This is termed as a 'Routing Group' in the data model.
<vspace blankLines='2' />
</t>
</list>
</t>
</section>
<section anchor="CategoryAdministration" title="Category: Administration">
<t>
<list style='format UC ADMIN #%d'>
<t hangText="">
New authoritative additions: An SSP provisions a public identity or TN Range, as its authoritative entity (i.e., carrier-of-record).
<vspace blankLines='2' />
</t>
<t hangText="">
New non-authoritative additions: An SSP provisions a public identity or TN Range, as a non-authoritative (i.e., transit) entity.
<vspace blankLines='2' />
</t>
<t hangText="">
Authoritative modifications to existing entries: An SSP indicates that it is the authoritative entity for an existing public identity or TN Range. If the public identity or TN Range was previously associated with a different authoritative entity then there are two possible outcomes: a) the previous authoritative entity is disassociated, or, b) the previous authoritative entity is relegated to non-authoritative status. The choice may be dependent on the deployment scenario, and is out of scope for this document.
<vspace blankLines='2' />
</t>
<t hangText="">
Non-authoritative modifications to existing entries: An SSP indicates that it is a transit provider for an existing public identity or TN Range. In such cases, this SSP is associated with the public identity or TN Range, in non-authoritative status.
<vspace blankLines='2' />
</t>
<t hangText="">
Authoritative disassociation from existing entries: An SSP disassociates itself from a public identity or TN Range that it is authoritative for. If there are no other (non-authoritative) SSPs associated with this public identity or TN Range, then the public identity may be deleted.
<vspace blankLines='2' />
</t>
<t hangText="">
Non-authoritative disassociation from existing entries: A SSP disassociates itself from a public identity or TN Range that it is linked with, as a non-authoritative entity. If there are no other authoritative or non-authoritative entities associated with this public identity or TN Range, the public identity may be deleted.
<vspace blankLines='2' />
</t>
<t hangText="">
Deletion of existing public identity or TN Range: A public identity (or a TN range) is taken out of service because it is no longer valid. The Registry receives a delete operation and removes the public identity from its database.
<vspace blankLines='2' />
</t>
<t hangText="">
EDITOR's Note: We may need to normalize the language here to use specified terms.
<vspace blankLines='2' />
Time-To-Live (TTL): For performance reasons, in favor of localized lookups, a query entity may decide to cache the answers and selectively query the resolution server when either the TTL expires or as a result of another out of band trigger. Therefore, the publishing entity should be able to *optionally* specify the TTL for a given route record. If the provisioning server doesn't support TTL option, it will result in a failure and a well-known error should be returned in the response.
<vspace blankLines='2' />
</t>
</list>
</t>
</section>
<section anchor="CategoryNumberPortability" title="Category: Number Portability">
<t>
<list style='format UC NP #%d'>
<t hangText="">
EDITOR's NOTE: We need to reconcile these two paragraphs.
<vspace blankLines='2' />
Routing Numbers: The SSP does not wish to provision individual TNs, but instead, for ease of management, wishes to provision Routing Numbers. Each RN represents a set of individual TNs, and that set of TNs is assumed to change 'automatically' as TNs are ported-in or ported-out. Note that this approach requires a query to resolve a TN to an RN prior to using the provisioned data to route.
<vspace blankLines='2' />
The SSP wishes to provide in query response to public identities an associated routing number or RN. This is the case when a set of public identities is no longer associated with original SSP but have been ported to a recipient SSP who provides access to these identities via a switch on the SS7 network identified by the RN. In this case a destination group containing all numbers that should be routed to this RN needs to be created and the route group associated with this DG needs to contain the RN
<vspace blankLines='2' />
</t>
<t hangText="">
Authoritative release: A release command associated with one or more public identities (or TN Ranges) is received from an authoritative entity indicating his relinquishing of authoritative "ownership" over the respective identities.
<vspace blankLines='2' />
EDITOR's NOTE: Can't this be achieved by an authoritative disassociation?
<vspace blankLines='2' />
</t>
<t hangText="">
Authoritative lock error: An existing public identity (or a TN range) is added indicating authoritative ownership by the provisioning entity. However, there may be cases where an explicit release is required. If so, and a release has not been provided, this will result in an error response.
<vspace blankLines='2' />
</t>
</list>
</t>
</section>
<section anchor="CategoryReview" title="Category: PLEASE REVIEW AND SEE IF THESE NEED TO BE ADDED">
<t>
<list style='format UC ID #%d'>
<t hangText="">
Global TN destinations: The SSP wishes to add or remove one or multiple fully qualified TN destinations in a single provisioning request.
<vspace blankLines='2' />
</t>
<t hangText="">
TN range destinations: The SSP wishes to add or remove one or multiple TN range destinations in a single provisioning request. TN ranges support number ranges that need not be 'blocks'. In other words the TN range 'start' can be any number and the TN range 'end' can be any number that is greater than the TN range 'start'.
<vspace blankLines='2' />
</t>
<t hangText="">
Non-TN destinations: An SSP chooses to peer their messaging service with another SSPs picture/video mail service. Allowing a user to send and receive pictures and/or video messages to a mobile user's handset, for example. The important aspect of this use case is that it goes beyond simply mapping TNs to IP addresses/hostnames that describe points-of-interconnect between peering network SSP's. Rather, for each user the SSP provisions the subscriber's email address (i.e. jane.doe@example.com). This mapping allows the mobile multimedia messaging service center (MMSC) to use the subscriber email address as the lookup key and route messages accordingly.
<vspace blankLines='2' />
</t>
<t hangText="">
Separation of responsibility: An SSP's operational practices can seperate the responsibility of provisioning the routing information, and the associated identities, to different entities. For example, a network engineer can establish a physical interconnect with a peering SSP's network and provision the associated domain name, host, and IP addressing information. Separately, for each new service subscription, the SSP's back office system provisions the associated public identities.
<vspace blankLines='2' />
</t>
<t hangText="">
Peering offer/acceptance: An SSP offers to allow terminations from another SSP by adding that SSP to a Data Recipient Group it controls. This causes notification of the offered SSP. An SSP receiving a peering offer should be able to accept or decline the offer. If the offer is rejected the registry should not provision corresponding SED to the rejecting SSP. It is expected that this capability will apply mainly in the transit case where non-authoritative parties (in the sense of not being the terminating SSP for an identity) wish to offer the ability to reach the identity and originating SSPs may wish to restrict the routes that are provisioned to their local data repositories.
<vspace blankLines='2' />
</t>
</list>
</t>
</section>
</section>
<section anchor="RegistryProvisioningRequirements" title="Requirements">
<t>
EDITOR's NOTE: !!!!!THIS NEEDS TO BE REVISED AFTER WE SIGN-OFF ON THE USE CASES!!!!!
<vspace blankLines='1' />
The following data requirements apply:
<list style='format DREQ%d:'>
<t hangText="">
The registry provisioning data model MUST support the following entities: public identities, destination groups, routing groups and data recipient groups.
<vspace blankLines='1' />
</t>
<t>
The registry provisioning data model MUST support the grouping and aggregation of public identities within destination groups.
<vspace blankLines='1' />
</t>
<t hangText="">
The registry provisioning data model SHOULD support the grouping and aggregation of TN Ranges within destination groups.
<vspace blankLines='1' />
</t>
<t hangText="">
The registry provisioning data model SHOULD support the grouping and aggregation of RNs within destination groups.
<vspace blankLines='1' />
</t>
</list>
<vspace blankLines='1' />
The following functional requirements apply:
<list style='format FREQ%d:'>
<t hangText="">
The registry provisioning interface MUST support the creation and deletion of: public identities, destination groups, routing groups and data recipient groups.
<vspace blankLines='1' />
</t>
<t hangText="">
The registry provisioning interface MUST support near-real-time, non-real-time and deferred provisioning operations.
<vspace blankLines='1' />
</t>
<t hangText="">
The registry provisioning interface MUST support the following types of modifications:
<vspace blankLines='1' />
- reassignment of one or more public identities from one destination group to another;
<vspace blankLines='1' />
- reassignment of one data recipient from one destination group to another;
<vspace blankLines='1' />
- association and disassociation of a "Default Routing Group" with a Data Recipient; and,
<vspace blankLines='1' />
- identification of a destination group as a "Carrier of Record" (COR) destination group or a "Transit" destination group.
<vspace blankLines='1' />
</t>
<t>
When an entity with a different client identifier than that of the carrier of record for a public identity in a destination group adds a new SSP to a destination recipient group associated with that destination group, the registry provisioning interface MUST: a) notify the new SSP of the updated routing information (which constitutes a peering offer) b) not provision the SED to the new SSP's LDR unless the new SSP signals acceptance.
</t>
<t>
The registry provisioning interface MUST separate the provisioning of the routing information from the associated identities.
<vspace blankLines='1' />
</t>
<t>
The registry provisioning protocol MUST define a discrete set of response codes for each supported protocol operation. Each response code MUST definitively indicate whether the operation succeeded or failed. If the operation failed, the response code MUST indicate the reason for the failure.
<vspace blankLines='1' />
</t>
<t>
The registry provisioning interface MUST allow an SSP to define multiple sub-identities that can be used in data recipient groups
</t>
<t>
The registry provisioning interface MUST define the concurrency rules, locking rules, and race conditions that underlie the implementation of that protocol operation and that result from the coexistence of protocol operations that can operate on multiple objects in a single operation and bulk file operations that may process for an extended period of time.
<vspace blankLines='1' />
</t>
<t>
The registry provisioning interface MUST support the ability for a Data Recipient to optionally define a Routing Group as their Default Routing Group, such that if the Data Recipient performs a resolution request and the lookup key being resolved is not found in the Destination Groups visible to that Data Recipient then the SED Records associated with the Default Routing Group shall be returned in the resolution response.
</t>
<t>
The registry provisioning interface MUST support the ability for the owner of a Routing Group to optionally define Source Based Routing Criteria to be associated with their Routing Group(s). The Source Based Routing Criteria will include the ability to specify zero or more of the following in association with a given Routing Group: Resolution Client IP Address(es) or Domain Names, Calling Party URI(s). The result will be that the resolution server would evaluate the characteristics of the Source, compare them against Source Based Routing Criteria associated with the Routing Groups visible to that Data Recipient, and return any SED Records associated with the matching Routing Groups.
</t>
<t>
The registry provisioning interface MUST track, via a client identifier, the entity provisioning each data object (e.g. Destination Group or Routing Group ). This client identifier will identify the entity that is responsible for that data object from a protocol interface perspective. This client identifier SHOULD be tied to the session authentication credentials that the client uses to connect into to the registry.
<vspace blankLines='1' />
The registry provisioning interface MUST incorporate a data recipient identifier that identifies the organization responsible for each data object from a business perspective. This organization identifier may or may not ultimately refer to the same organization that the client Identifier refers to. The separation of the data recipient identifier from the client identifier will allow for the separation of the two entities, when the need arises.
<vspace blankLines='1' />
Exactly one client identifier MUST be allowed to provision objects under a given data recipient identifier. But a client identifier MUST be allowed to provision objects under multiple data recipient identifiers.
<vspace blankLines='1' />
Objects provisioned under one "Protocol Client Identifier" MUST NOT be alterable by a provisioning session established by another "Protocol Client Identifier".
<vspace blankLines='1' />
</t>
<t>
The registry provisioning protocol MUST allow an SSP to provision LUF-only or LUF+LRF data in the registry via a single provisioning interface and data model.
<vspace blankLines='1' />
</t>
</list>
</t>
</section>
</section>
<!--
<section anchor="DistributionOfDataIntoLocalDataRepositories" title="Distribution of data into local data repositories">
<t>
This section targets use cases concerned with the distribution of SED to local data repositories. This is considered out-of-scope for this version of the document.
<list style='numbers'>
<t hangText="">
Provisioning a Public Identify or set of Public Identities at an effective date/time.
</t>
<t hangText="">
A Public Identify is taken out of service at an effective date/time.
</t>
<t hangText="">
Assigning a set of Public Identities to a different destination group, thereby changing their routing.
</t>
</list>
</t>
</section>
-->
<!--
<section anchor="PeeringRelationships" title="Peering Relationships">
<t>
This section contains use cases pertaining to peering relationships.
</t>
</section>
<section anchor="SIPServiceProvider" title="SIP Service Provider">
<t>
</t>
</section>
<section anchor="LRFandLUF" title="LRF and LUF">
<t>
This Section contains use cases related to LRF and LUF. They are presented in the following sub-sections.
</t>
<section anchor="LRFusecases" title="LRF">
<t>
<list style='numbers'>
<t hangText="">
Source service provider direct connection (bi-lateral): A service provider may be connected directly with a peer network hosting the ultimate SIP destination. The source service provider is able to translate the information provided by the LUF to obtain the ingress point to the network containing the ultimate destination.
</t>
<t hangText="">
Source service provider direct connection (bi-lateral): A service provider may be connected directly with a peer network hosting the SIP destination. The source service provider is not able to translate the information received from the LUF to an ingress point for the network containing the ultimate destination.
</t>
<t hangText="">
Source service provider direct connection (bi-lateral): A service provider may be connected directly with a peer network not hosting the SIP destination. The Source service provider is not able to translate to the ultimate destination because the LUF does not contain a translation. The selected target network is able to perform the LUF to identify the ultimate destination.
</t>
<t hangText="">
Source service provider is not connected directly with a peer network hosting the ultimate SIP destination rather through an intermediate transit network which is connected to a peer network hosting the ultimate SIP destination. Note that variations in use cases 1, 2 & 3 all apply.
</t>
<t hangText="">
Source service provider is not connected directly with a peer network hosting the ultimate SIP destination, rather to a clearing house network which is connected to a peer network hosting the ultimate SIP destination.
</t>
<t hangText="">
Source service provider is not connected directly with a peer network hosting the ultimate SIP destination rather through more than one intermediate transit networks which are all connected to a peer network hosting the ultimate SIP destination. The source service provider has to chose the transit service provider to select.
</t>
<t hangText="">
Source service provider has multiple paths to a destination network both on inter-network connections and inter-transit network connections. The source service provider wants to select different transit networks and different routes to those networks based on various criteria such as traffic load, capacity, cost, latency, etc.
</t>
<t hangText="">
Roaming mobile user uses IMS service accessed through local breakout, the service is located outside the serving network.
</t>
<t hangText="">
Roaming mobile user is disconnected from emergency service call (via IMS local breakout). The PSAP is located in a network outside of the serving network. The PSAP initiates a callback to the mobile which should go to the serving network, not the home network from the network the PSAP is located in.
</t>
<t hangText="">
A transit network connected to the source service provider has had a route change or a network connectivity change which needs to be communicated to its peer networks.
</t>
<t hangText="">
A transit network has a change in the domains it is able to reach (added, dropped/unavailable, route change) which it needs to send to its peer networks.
</t>
<t hangText="">
The transit network uses LRF to route internally to the network and to select one of several possible exit points, next hop transit network and specific connection between networks.
</t>
<t hangText="">
The service provider may have fixed domain routing specified in the LRF which overrides the domain routing provided by peer networks.
</t>
<t hangText="">
The service provider may have fixed routing specified in the LRF as a default until a peer network identifies it is able to provide alternate (better) routing.
</t>
</list>
</t>
</section>
<section anchor="LUFusecases" title="LUF">
<t>
A service provider's LUF is connected to several different Registries some for national numbers, some for enterprise identifiers (e.g. @example.com translating to @example.nt for an enterprise user who has a mobile with a public user identity or GRUU (3GPP TS 23.228) which is part of an enterprise domain. {What if there is a collision and conflict between some particular number or domain between registries?}
</t>
</section>
</section>
<section anchor="SSP" title="SSP">
<t>
This Section contains SIP Service Provider specific use cases. They are presented in the following sub-sections.
</t>
<section anchor="GenericSSP" title="Generic SSP">
<t>
An SSP provisions a registry to offer different routes to different interconnecting parties. The SSP uses the same routes for an aggregation of public identities (e.g., TNs) and desires to be able to specify routing for the aggregate. Routes consist of a set of RRs of any legitimate type.
</t>
</section>
<section anchor="SmallSSP" title="Small SSP">
<t>
The small SSP provides coverage to a small city only with 3 different peer interconnects: 1) To another small SSP covering an adjacent small city; 2) to a mid-sized SSP providing coverage to the remainder of the state; 3 to a large multi-national SSP providing SSP transit services for the remainder of the world.
</t>
<section anchor="ConfiguringsmallSSProuting" title="Configuring small SSP routing">
<t>
The small SSP with a small number of SSP peer arrangements prefers to statically define and provision the SED routing through network engineering tools by the network engineering staff. This is because the domain coverage of each peer SSP will not change very frequently and the small SSP does not want to incur the cost and complexity of a dynamically established routing data.
</t>
</section>
<section anchor="SmallSSPLUFLRFconsolidation" title="Small SSP LUF/LRF consolidation">
<t>
A small SSP only needs a single network element to handle its entire LUF/LRF needs and as such combines the LUF and LRF. The routing associations in this network element are provisioned statically through network management tools by network operation or engineering staff.
</t>
</section>
</section>
<section anchor="LargeSSP" title="Large SSP">
<t>
The large SSP provides coverage to a large country: the SSP is administratively divided into regions. The SSP provides SSP transit services to smaller SSPs operating in the same areas. The SSP has both direct SSP connections for national and international service and indirect SSP connections for international service to some countries based on traffic levels. This results in multiple possible routes to some destination SSPs through different intermediate SSPs. Each SSP region has a different sub-set of peer SSPs that it is directly connected to (e.g. Some regions may have to route internally to another SSP region to reach the destination SSP).
</t>
<section anchor="ConfiguringlargeSSProuting" title="Configuring large SSP routing">
<t>
The large SSP has a large number of direct and indirect peer arrangements along with multiple possible routes to the same destination SSP. The large SSP prefers to only provision the SSP peers and have the elements such as SBCs learn the routes based on peer SSP advertisements to eliminate routing errors (loops, dead ends, etc.) which are service affecting and almost impossible to troubleshoot in a network of this size.
</t>
</section>
<section anchor="LargeSSPLUFLRFseparationandLRFdistribution" title="Large SSP LUF/LRF separation and LRF distribution">
<t>
A large SSP needs to centralize its LUF but split off the LRF for deployment in decentralized regional network elements. The routing associations in the regional LRFs are provisioned dynamically through advertisements by the large SSP peering SSPs regarding which domains they are able to handle.
</t>
</section>
<section anchor="Large SSP peering with a small SSP" title="Large SSP peering with a small SSP">
<t>
A large SSP peers with a small SSP. The small SSP is unable to support the cost and complexity of dynamically advertising to its peer SSPs the domains it is able to reach directly or indirectly. The large SSP provisions routing association data statically representing the domains which the small SSP can reach either directly or indirectly, through network management tools by network operation or engineering staff.
</t>
</section>
</section>
</section>
-->
</section>
<section anchor="security" title="Security Considerations">
<t>
Session establishment data allows for the routing of SIP sesions within, and between, SIP Service Providers. Access to this data can compromise the routing of sessions and expose a SIP Service Provider to attacks such as service hijacking and denial of service. The data can be compromised by vulnerable functional components and interfaces identified within the use cases.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document does not register any values in IANA registries.
</t>
</section>
<section title="Acknowledgments">
<t>
This document is a result of various discussions held by the DRINKS requirements design team, which is comprised of the following individuals, in alphabetical order: Deborah A Guyton (Telcordia), Gregory Schumacher (Sprint), Jean-Francois Mule (CableLabs), Kenneth Cartwright (TNS, Inc.), Manjul Maharishi (TNS, Inc.), Penn Pfautz (AT&T Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey, Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of this document.
<vspace blankLines='1'/>
This specific version of the document is a result of contributions from, primarily, David Schwartz (XConnect), Kenneth Cartwright (TNS, Inc.) and Syed Ali (Neustar, Inc.). Other participants who reviewed and provided comments include: Alexander Mayrhofer (enum.at GmbH), Jean-Francois Mule (CableLabs), Manjul Maharishi (TNS, Inc.), and other participants on the DRINKS mailing list.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
&rfc3261;
&rfc3263;
&rfc5486;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 16:09:18 |