DRINKS                                             S. Channabasappa, Ed.
Internet-Draft                                                 CableLabs
Intended status: Informational                             March 8,                               May 3, 2010
Expires: September 9, November 4, 2010

               DRINKS Use cases and Protocol Requirements
               draft-ietf-drinks-usecases-requirements-01
               draft-ietf-drinks-usecases-requirements-02

Abstract

   This document captures the use cases and associated requirements for
   interfaces to that provision session establishment data into SIP Service
   Provider components that aid components, to assist with session routing.  Specifically,
   the current version of this document focuses on the provisioning of
   one such element, termed the registry.

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. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   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, November 4, 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 Simplified BSD License.

Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5  4
   3.  Use Cases and Requirements . . . . . . . . . . . . . . . . . . 10  8
     3.1.  Registry Provisioning  . . . . . . . . . . . . . . . . . . 10  8
       3.1.1.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . 10  8
       3.1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . 15
     3.2.  Distribution of data into local data repositories  . . . . 18 14
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19 18
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20 19
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21 20
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 21
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 22 21
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 22 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 22

1.  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] (e.g., SIP) and [RFC5486]
   (e.g., LUF, LRF).  In addition, this document specifies the following
   additional terms.

   Registry:   The authoritative source for provisioned session
      establishment data (SED) and related information.

   Local Data Repository:   The data store component of an addressing
      server that provides resolution responses.

   Destination Group:   A set of public identities that are grouped
      together to facilitate session setup and routing.

   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).

   Routing Group:   a   A grouping of SED records.

   SED Record:   A SED Record contains much of the session establishment
      data

   Authoritative SSP or a 'redirect' Entity  This refers to another registry where the session
      establishment data can be discovered.  SED Records types supported
      are NAPTRs, CNAME, DNAME, and NS Records.

   Data Recipient:   SP carrier-of-record,
      for a public identity or TN Range.

   Non-authoritative SSP that receives or consumes SED and related
      information.

   Data Recipient Group:   A group of Data Recipients that receive Entity  This refers to the
      same set (or subset) of SED and related information. transit provider
      for a public identity or TN Range.

2.  Overview

   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 complete the call. establish a session.  See [RFC5486] for more details.

   The specification of the format and protocols to configure 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.

   SED is typically created by the terminating SSP and consumed by the
   originating SSP.  For scalability reasons  To avoid a multitude of bilateral exchanges, SED is rarely exchanged
   directly between the intended parties.  Instead, it is exchanged
   usually shared via
   intermediate 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 Figure 1.

                                       *-------------*
                1. Provision SED       |             |
              -----------------------> |  Registry   |
                                       |             |
                                       *-------------*
                                            /  \
                                           /    \
                                          /      \
                                         /        \
                                        /          \
                                       /            \
                                      / 2.Distribute \
                                     /      SED       \
                                    V                  V
                              +----------+       +----------+
                              |Local Data|       |Local Data|
                              |Repository|       |Repository|
                              +----------+       +----------+

                         Figure 1: General Diagram

   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 Figure 2.

                                  . . . . . . .
                  . . . .  . . .   registry    . . . . . . .
                .                 . . . . . . .              .
              .                        .                      .
            .                          . provision             .
       +-----------+                   .                 +-----------+
       |           |  provision  +----------+  provision |           |
       |   SSP 1   |------------>| Registry |<-----------|   SSP 2   |
       |           |             +----------+            |           |
       |  +-----+  |                   /\                |  +-----+  |
       |  | LDR | <--------------------  ------------------>| LDR |  |
       |  +-----+  |   distribute           distribute   |  +-----+  |
       |           |                                     |           |
       +-----------+                                     +-----------+
              .                                                .
               . . . . . . . . . . . . . . . . . . . . . . . .
                              (provision / distribute)

             Where, LDR = Local Data Repository

                       Figure 2: Functional Overview

   The following is a summary of the proposed responsibilities for
   Registries and Local Data Repositories:

   o  Registries are the authoritative source for provisioned session
      establishment data (SED) and related information.

   o  Local Data Repositories are the data store component of an
      addressing server that provides resolution responses.

   o  Registries are responsible for distributing SED and related
      information to the local data repositories.

   In addition, this document proposes the following aggregation groups
   with regards to SED (certain use cases also illustrate these groups):

   o  Aggregation of public Identifiers: The initial input 'key' (refer to a
      SED lookup is a public identifier.  Since many public identifiers
      will share similar (or identical) destinations, and hence return
      similar (or identical) SED, provisioning the same set of SED for
      millions of public identifiers is inefficient, especially in use cases
      where in Section 3.1.1.3 for
   the SED needs to be modified.  Therefore, an aggregation
      mechanism to 'group' public identifiers is proposed.  This
      aggregation is called a 'destination group'. rationale):

   o  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'. public Identifiers into a destination group.

   o  Aggregation of SED records: Finally, it is anticipated that records into a
      complete set of routing data will 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 at this level is proposed, and called
      'Routing Group'. Routing Group.

   The above aggregations are illustrated in Figure 3.

       +---------+            +--------------+
       |  Data   | 0..n     1 |DATA RECIPIENT|
       |Recipient|------------|     GROUP    |
       +---------+            +------.-------+
                                0..n |
                                     |
                                     |
                                   1 |
                              +--------------+               +---------+
       |  Data   |0..n       1|    ROUTING   | ------------->| 1         0..n|   SED   |
                              |
       |Recepient|------------|     GROUP    | 1        0..n | --------------|  Record |
       +---------+            +--------------+               +---------+
                                     |0..n                        |0..n
                                     |                            |
                                     |                            |
                                     |                            |
                                     | 1                          |
                         1..n +--------------+  0..n              |
                     ---------| DESTINATION  |---------           |
                    |         |    GROUP     |         |          |
                    |         +--------------+         |          |
                    |                |                 |          |
                    |            1..n|                 |          |
                    |                |                 |          |
                    |                |                 |          |
                  1 |              1 |                 | 1        |
               +---------+      +---------+       +---------+     |
               |   RN    |      |   TN    |       | Public  |-----
               |         |      |  Range  |       |Identity | 1
               +---------+      +---------+       +---------+

                       Figure 3: Data Model Diagram

   Additional clarifications follow:

   -  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".

   -  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.

   -  A data recipient group contains zero or more data recipients to
      facilitate the allocation of access privileges to routing groups.

3.  Use Cases and Requirements

   This section presents the use cases and associated requirements.

3.1.  Registry Provisioning

   Registry is

   This Section documents use cases related to the authoritative source for session establishment data
   (SED).  The registry needs provisioning of the
   registry.  Any request to be provisioned with this provision, modify or delete data is subject
   to
   perform its function.  This data includes: destination groups,
   routing groups and data recipient groups.  It can also include RNs
   and TN Ranges.  The following sub-sections illustrate the use cases
   and authorization.  However, the requirements, respectively. act of authorization is considered
   out of scope within this document.

3.1.1.  Use Cases

   The use cases are divided into the following categories - process,
   routing, identity, different
   provisioning options, options for provisioning SED data,
   administration, and number portability.

3.1.1.1.  Category: Process Provisioning Options

   UC PROCESS #1  Near-real-time  Real-time provisioning: The once a registry is
                  provisioned with data established
                  events may occur that is not accompanied by an
                  effective date necessitate SSPs to add, modify
                  or time.  In such cases, delete data in the registry
                  will validate registry, in real-time, to
                  maintain accuracy of the data and make it effective data.  Examples of such
                  events can be found in near
                  real-time. other use cases within this
                  document (e.g., identity related use cases).

   UC PROCESS #2  Deferred provisioning with effective date/time: The  Non-real-time or bulk provisioning: There are cases
                  when a registry is needs to be provisioned with bulk data that is accompanied
                  by
                  sets, via an effective date and time.  In scenarios such offline mechanism, as
                  this, the registry will validate the data and wait
                  until the effective date and time opposed to make it
                  effective.  TBD: What happens if near-real real-
                  time data
                  overrides data parked for later incorporation?

   UC PROCESS #3  Batch provisioning: The registry is provisioned via an
                  asynchronous provisioning process.  For instance, an
                  SSP has commissioned requests.  Examples include: when a
                  new registry and wishes to
                  download a very large number of telephone numbers.
                  Rather than stream individual entities, one at is established or when data is being
                  restored from a time,
                  the SSP's back-office system prefers to perform the
                  operation as a set of one or more batches (e.g., via
                  an external data file), instead of the near-real-time
                  provisioning interface. backup.

3.1.1.2.  Category: Routing SED options

   UC ROUTING SED DATA #1  Intra-network  Inter-network SED: An SSP wishes to provision their
                  intra-network Session Establishment Data (SED) such provisons SED records for a
                   specific end-user, so that it enables current and future network services to
                  identify and route real-time sessions.  For example,
                  in the case of VoIP calls it allows one SoftSwitch
                  (calling) other SSPs can use this
                   SED data to discover another (called). establish sessions intended with this
                   end-user.  The provisioning SSP
                  provisions IP addressing information pertaining can either be the
                   carrier-of-record (direct peering), or a transit
                   provider (indirect peering).

   UC SED DATA #2  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
                  each SoftSwitch, which is
                   establish sessions intended for this end-user.  The
                   provisioned to the registry
                  but SED is only distributed to a specific local
                   data
                  repository.  This SED may repositories, and will probably differ from the
                   SED that is
                  distributed to provisioned for use by signaling elements from
                   other local data repositories. SSPs.

   UC ROUTING #2  Support SED DATA #3  Selective peering: While an SSP may provision the
                   same SED records for destination groups: An all other SSPs, an SSP may also
                   wish to
                  control provision different SED records for different
                   SSPs (e.g., if they have different peering
                   agreements).

   UC SED DATA #4  LUF-only data: An SSP can choose to provison LUF-only
                   data in the flow of traffic into their network
                  (ingress) based registry.  A querying SSP that receives
                   LUF-only data may need to rely on groupings of Public Identities.
                  Associating each group of Public Identities with a
                  specific set of ingress SBEs or points-of-
                  interconnect.  The SSP, other mechanisms
                   (e.g., [RFC3263] for example, sub-divides the
                  country into four regions: North-East, South-East,
                  Mid-West, domain-name based LUF) to obtain
                   LRF information.

   UC SED DATA #5  LUF and West-Coast.  For each region they
                  establish points-of-interconnect with peers LRF data: An SSP can provison LUF- and
                  provision LRF-
                   data in the associated SED hostnames or IP addresses
                  of registry.  In such cases, the SBEs used for ingress traffic.  Against each
                  region they provision the served Public Identities
                  into groups- termed Destination Groups - and associate
                  those destination groups with the appropriate points
                  of ingres.

   UC ROUTING #3  Modifying destination groups: A set of public
                  identities are assigned a different Destination Group
                  which effectively changes their querying
                   SSP does not have to rely on mechanisms such as DNS
                   (e.g., [RFC3263]) for routing information.
                  This may be due to a network re-arrangement,

   UC SED DATA #6  Target Domain as a
                  Signaling path Border Element being split into two, resolvable Domain Name,
                   administrative domain name, or
                  a need both: The target
                   domain pertaining to do maintenance, two carriers merging, a public identity or
                  other considerations.  This scenario TN Range
                   can also include either be a DNS-resolvable domain name (i.e., via
                   [RFC3263]) or an effective date and time.

   UC ROUTING #4  Indirect Peering to Selected Destinations: The administrative domain.  An SSP
                  transit provider wishes may
                   also wish to provide transit peering
                  points for a set of destinations.  But that set provision both sets of
                  destinations does not align with data, and the destination
                  groups that already exist.
                   response is based on a default choice or the querying
                   entity.

   UC SED DATA #7  Target Domain as an administrative domain: The SSP wishes to
                  establish its own destination groups target
                   domain for a public identity or TN Range can be an
                   administrative domain.  In such cases the
                  destinations that it provides transit to.  (Editor's
                  note: resolution
                   may be out of scope for this document.

   UC SED DATA #8

   UC SED DATA #9  EDITOR's NOTE: This use case needs more work.)

   UC ROUTING #5  Inter-network SED (direct and selective peering): In
                  this seems to be a special
                   case the of LUF-only provisioning.  Thoughts?

                   Provision an authoritative name server: An SSP is
                   maintains a Tier 2 name server that contains the actual carrier-of-record;
                   NAPTR records that constitute the
                  entity serving terminal step in
                   the end-user. LUF.  The SSP wishes to
                  communicate different SED data needs to some of its peers
                  that wish provision an registry to route
                   direct queries for the SSPs numbers to its destinations.  So the SSP
                  has implemented direct points-of-interconnect with
                  each peer and therefore would like address-resolution Tier 2.
                   Usually queries to result the registry should return NS
                   records, but, in different answers depending on which peer
                  is asking. cases where the Tier 2 uses a
                   different domain suffix from that used in the
                   registry, CNAME and NS records may be employed
                   instead.

3.1.1.3.  Category: Data Aggregations

   UC ROUTING #6  Selecting egress points: An SSP has DATA #1  Aggregation of public Identifiers: The input key to a peering
                  relationship with SED
               lookup is a peer, public identifier.  Since several public
               identifiers will potentially share similar (or identical)
               destinations, and when sending messages to
                  that peer's point of interconnection, hence similar (or identical) SED
               records, provisioning the originating
                  SSP wishes to use one or more points of egress.  These
                  points same set of egress may vary SED for an given peer.  This
                  capability millions of
               public identifiers is supported by allowing inefficient.  Therefore, an originating SSP
                  to provision SED for identities terminating
               aggregation mechanism to other
                  SSPs where the originating SSP 'group' public identifiers is itself
               proposed.  This aggregation is termed as a 'destination
               group' in the proposed data
                  recipient.  The provisioning SSP may make use model.

   UC DATA #2  Aggregation of
                  multiple SED records: A complete set of session
               establishment data recipient identities if it requires
                  different sets may consist of egress points more than just one SED
               record.  To be used for calls
                  originating from different parts of its network.
                  Routing from egress points able to ingress points 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
                  terminating data model.

3.1.1.4.  Category: Administration

   UC ADMIN #1  New authoritative additions: An SSP may be accomplished by static routing
                  from the egress points provisions a public
                identity or by the egress points using
                  data provisioned to the Registry by the terminating
                  SSP. TN Range, as its authoritative entity (i.e.,
                carrier-of-record).

   UC ROUTING #7 ADMIN #2  New non-authoritative additions: An SSP prefers provisions a
                public identity or TN Range, as a non-authoritative
                (i.e., transit) entity.

   UC ADMIN #3  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.

   UC ADMIN #4  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.

   UC ADMIN #5  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.

   UC ADMIN #6  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.

   UC ADMIN #7  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.

   UC ADMIN #8  EDITOR's Note: We may need to normalize the language
                here to use specified terms.

                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.

3.1.1.5.  Category: Number Portability

   UC NP #1  EDITOR's NOTE: We need to reconcile these two paragraphs.

             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 provision LUF and LRF data in using the
                  registry: provisioned data to route.

             The SSP prefers the registry wishes to have access provide in query response to
                  LUF and LRF information.  In this case public
             identities an associated routing number or RN.  This is the originating
             case when a set of public identities is no longer
             associated with original SSP does not but have been ported to rely on mechanisms such as DNS
                  (e.g., [RFC3263]) for routing information since a
                  registry query will return the terminating SBE.

   UC ROUTING #8  Provision an authoritative name server (not actual
                  route): An
             recipient SSP maintains who provides access to these identities via a Tier 2 name server that
                  contains the NAPTR records that constitute the
                  terminal step in
             switch on the LUF.  The SSP needs to provision
                  an registry to direct queries for SS7 network identified by the SSPs RN.  In this
             case a destination group containing all numbers that should
             be routed to
                  the Tier 2.  Usually queries this RN needs to be created and the registry should
                  return NS records, but, in cases where route
             group associated with this DG needs to contain the Tier 2 uses
                  a different domain suffix RN

   UC NP #2  Authoritative release: A release command associated with
             one or more public identities (or TN Ranges) is received
             from that used in an authoritative entity indicating his relinquishing
             of authoritative "ownership" over the
                  registry, CNAME and NS records may respective
             identities.

             EDITOR's NOTE: Can't this be employed
                  instead.

3.1.1.3.  Category: Identity achieved by an authoritative
             disassociation?

   UC ID #1  Deletion of public identity: A NP #3  Authoritative lock error: An existing 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.  This can
             also trigger delete operations to keep added indicating authoritative ownership by
             the local data
             repositories up-to-date. 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.

3.1.1.6.  Category: PLEASE REVIEW AND SEE IF THESE NEED TO BE ADDED

   UC ID #2 #1  Global TN destinations: The SSP wishes to add or remove one
             or multiple fully qualified TN destinations in a single
             provisioning request.

   UC ID #3 #2  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'.

   UC ID #4 #3  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.

   UC ID #5  LUF-only provisioning: SSP wants to provision the registry
             for LUF lookup only and prefers LRF to be accomplished via
             non-registry mechanisms.  In this case the registry lookup
             will return a domain name and the originating SSP will rely
             on mechanisms such as ([RFC3263]) to obtain routing
             information.  This routing information is managed by the
             (terminating) SSP, via DNS mechanisms.

3.1.1.4.  Category: Administration

   UC ADMIN #1  Moving an SSP from one data recipient group to another:
                An SSP would like to re-assign the destination groups it
                shares with a peer and move the peer SSP from one Data
                Recipient Group to another.  This results in the moved
                peer seeing a new and different set of routing data.

   UC ADMIN #2 #4  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.

   UC ADMIN #3 ID #5  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 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.

3.1.1.5.  Category: Number Portability

   UC NP #1  The SSP does not wish to provision individual TNs, but
             instead, for ease of management, wishes to provision
             Routing Numbers (e.g., as in some number portability
             implementations).  Each RN effectively represents a set of
             individual TNs, and that set of TNs is assumed to change
             'automatically' as TNs are ported in and ported out.  Note
             that this approach requires a query to resolve a TN to an
             RN prior to using the provisioned data to route.

3.1.2.  Requirements

   EDITOR's NOTE: !!!!!THIS NEEDS TO BE REVISED AFTER WE SIGN-OFF ON THE
   USE CASES!!!!!
   The following data requirements apply:

   DREQ1:  The registry provisioning data model MUST support the
           following entities: public identities, destination groups,
           routing groups and data recipient groups.

   DREQ2:  The registry provisioning data model MUST support the
           grouping and aggregation of public identities within
           destination groups.

   DREQ3:  The registry provisioning data model SHOULD support the
           grouping and aggregation of TN Ranges within destination
           groups.

   DREQ4:  The registry provisioning data model SHOULD support the
           grouping and aggregation of RNs within destination groups.

   The following functional requirements apply:

   FREQ1:   The registry provisioning interface MUST support the
            creation and deletion of: public identities, destination
            groups, routing groups and data recipient groups.

   FREQ2:   The registry provisioning interface MUST support near-real-
            time, non-real-time and deferred provisioning operations.

   FREQ3:   The registry provisioning interface MUST support the
            following types of modifications:

            - reassignment of one or more public identities from one
            destination group to another;

            - reassignment of one data recipient from one destination
            group to another;

            - association and disassociation of a "Default Routing
            Group" with a Data Recipient; and,

            - identification of a destination group as a "Carrier of
            Record" (COR) destination group or a "Transit" destination
            group.

   FREQ4:   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.

   FREQ5:   The registry provisioning interface MUST separate the
            provisioning of the routing information from the associated
            identities.

   FREQ6:   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.

   FREQ7:   The registry provisioning interface MUST allow an SSP to
            define multiple sub-identities that can be used in data
            recipient groups

   FREQ8:   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.

   FREQ9:   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.

   FREQ10:  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.

   FREQ11:  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.

            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.

            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.

            Objects provisioned under one "Protocol Client Identifier"
            MUST NOT be alterable by a provisioning session established
            by another "Protocol Client Identifier".

   FREQ12:  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.

3.2.  Distribution of data into local data repositories

   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.

4.  Security Considerations

   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.

5.  IANA Considerations

   This document does not register any values in IANA registries.

6.  Acknowledgments

   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.

   This specific version is primarily of the document is a result of feedback from contributions
   from, primarily, David Schwartz (Xconnect) (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), with input
   from Manjul Maharishi (TNS, Inc.), and
   other participants listed above. on the DRINKS mailing list.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [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.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC5486]  Malas, D. and D. Meyer, "Session Peering for Multimedia
              Interconnect (SPEERMINT) Terminology", RFC 5486,
              March 2009.

Author's Address

   Sumanth Channabasappa
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   USA

   Email: sumanth@cablelabs.com