DRINKS                                             S. Channabasappa, Ed.
Internet-Draft                                                 CableLabs
Intended status: Informational                              May 3, 25, 2010
Expires: November 4, 26, 2010

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

Abstract

   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.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   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."

   This Internet-Draft will expire on November 4, 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Registry Use Cases and Requirements . . . . . . . . . . . . . . . . . .  8 . . . .  9
     3.1.  Registry  Category: Provisioning Mechanisms  . . . . . . . . . . . .  9
     3.2.  Category: Interconnect Schemes . . . . . . . . . .  8
       3.1.1.  Use Cases . . . .  9
     3.3.  Category: SED Exchange and Discovery Models  . . . . . . . 11
     3.4.  Category: SED Record Content . . . . . . . . . . . .  8
       3.1.2.  Requirements . . . 12
     3.5.  Category: Separation and Facilitation of Data
           Management . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.6.  Category: Lookup Keys  . . . . . . . . . . . . . . . . . . 13
     3.7.  Category: Number Portability . . . . . . . . . . . . . . . 14
     3.8.  Category: Misc . . . . . . . . . . . . . . . . . . . . . . 14
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   5.
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   6.
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   7.
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     7.1.
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     7.2.
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 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 SIP), [RFC5486]
   (e.g., LUF, LRF). LRF, SED) and [RFC5067] (carrier-of-record and transit
   provider).  In addition, this document specifies the following
   additional terms.

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

   Registrar  An entity that provisions and manages data into the
      registry.

   Registrant  An entity whose data is provisioned into the registry.
      The registrant can act as its own registrar or - additionally or
      alternatively - delegate this function to a third party who acts
      as its registrar.

   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: Identifier:   A generic term that public identifier 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:

   TN Range:   A grouping numerically contiguous set of telephone numbers whose
      SED records.

   Authoritative SSP or Entity  This refers to the carrier-of-record,
      for can be looked up (resolved).

   Destination Group:   An aggregation of a set of public identity or identifiers,
      TN Range.

   Non-authoritative SSP Ranges, or Entity  This refers to the transit provider
      for RNs that share common SED.

   Data Recipient:   An entity with visibility into a specific set of
      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 identifiers, the next hop destination groups that contain these
      public identifiers, and a routing group's SED records.

   Routing Group:   An aggregation that contains a related set of SED
      records, and is associated with a set of destination groups.
      Routing groups facilitate the management of SED records - which
      are common to a large number of public identifiers, TN Ranges or
      RNs - for one or more data recipients.

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 signaling path border elements (SBEs)
   need to establish a session.  See [RFC5486] for more details.

   The specification of the format and protocols to provision SED is a
   task taken up by the DRINKS WG.  The  This document contains the use cases
   and requirements that have been proposed in this regard are compiled in this document. regard.

   SED is typically created by the terminating SSP and consumed by the
   originating SSP.  To avoid a multitude of bilateral exchanges, SED is
   usually
   often shared via intermediary systems - termed Registries 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. distribution to local data repositories.  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 (refer to the use cases in Section 3.1.1.3 3.5 for the
   rationale):

   o  Aggregation of public Identifiers into a destination group.

   o  Aggregation of SED records into a Routing Group.

   The above aggregations are illustrated data model depicted in Figure 3. 3 shows the various entities,
   aggregations and the relationships between them.

       +---------+            +--------------+               +---------+
       |  Data   |0..n       1|    0..n|    ROUTING   | 1         0..n|   SED   |
       |Recepient|------------|     GROUP    | --------------|  Record |
       +---------+            +--------------+               +---------+
                                     |0..n                        |0..n
                                     |                            |
                                     |                            |
                                     |                            |
                                     |0..n                        |
                            1                          |
                         1..n +--------------+  0..n  0..1              |
                     ---------| DESTINATION  |---------           |
                    |         |    GROUP     |         |          |
                    |         +--------------+         |          |
                    |                |                 |          |
                    |            1..n|               1|                 |          |
                    |                |                 |          |
                    |                |                 |          |
                  1
               0..n |              1           0..n |                 | 1 0..n     |
               +---------+      +---------+       +---------+       +----------+    |
               |   RN    |      |   TN    |       | Public  |-----   |----
               |         |      |  Range  |       |Identity |       |Identifier| 1
               +---------+      +---------+       +---------+       +----------+

                       Figure 3: Data Model Diagram

   Additional clarifications follow:

   The relationships are as described below:

   -  A routing group is Data Recipient object can be associated with zero or more SED Records;
      NAPTRs
      Routing Group objects, and other SED record types associated with routes are not
      user a Routing Group object can refer to
      zero or TN-specific.  For example the user portion of more Data Recipient objects.

   -  A Routing Group object can contain zero or more SED Record
      objects, and a NAPTR
      regular expression will SED Record object can be "\1". contained in exactly one
      Routing Group object.

   -  A routing group is Routing Group object can be associated with zero or more peering
      organizations to control visibility or access privileges to that
      routing group
      Destination Group objects, and the destination groups they expose. a Destination Group object can be
      associated with zero or more Routing Group objects.

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

3.  Use Cases RN objects,
      and Requirements

   This section presents the use cases an RN object can be contained in exactly one Destination Group
      object.

   -  A Destination Group object can contain zero or more TN Range
      objects, and associated requirements.

3.1. a TN Range object can be contained in exactly one
      Destination Group object.

   -  A Destination Group object can contain zero or more Public
      Identifier objects, and a Public Identifier object can be
      contained in exactly one Destination Group object.

3.  Registry Provisioning Use Cases

   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 to
   be out of scope within this document.

3.1.1.  Use Cases

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

3.1.1.1.

3.1.  Category: Provisioning Options Mechanisms

   UC PROCESS PROV #1  Real-time provisioning: once a registry is established
                  events may occur  Real-Time Provisioning: Registrars have operational
               systems that necessitate SSPs to add, modify
                  or delete data in the registry, provision public identifiers, in real-time, to
                  maintain accuracy of the data.  Examples of such
                  events can be found association
               with their SED.  These systems often function in other use cases within this
                  document (e.g., identity related use cases).

   UC PROCESS #2  Non-real-time or bulk provisioning: There are cases
                  when a registry needs to manner
               that expect or require that these provisioning activities
               be provisioned with bulk data
                  sets, via an offline mechanism, completed immediately, as opposed apposed to real-
                  time an out-of-band or
               batch provisioning requests.  Examples include: when scheme that can occur at a
                  new registry later time.
               This type of provisioning is established referred to as real-time, or when data is being
                  restored from a backup.

3.1.1.2.  Category: SED options
               on-demand provisioning.

   UC SED DATA #1  Inter-network SED: An SSP provisons SED records for a
                   specific end-user, so PROV #2  Non-Real-Time Bulk Provisioning: Operational systems that other SSPs can use this
               provision public identifiers and associated SED data to establish sessions intended with this
                   end-user.  The sometimes
               expect that these provisioning SSP can either activities be the
                   carrier-of-record (direct peering), or batched up
               into large sets.  These batched requests are then
               processed using a transit
                   provider (indirect peering). provisioning mechanism that is out-of-
               band and occurs at a later time.

   UC SED DATA #2  Intra-network SED: An SSP provisons SED records for PROV #3  Multi-Request Provisioning: Regardless of whether a
                   specific end-user,
               provisioning action is performed in real-time or not,
               SSPs often perform several provisioning actions on
               several objects in a single request or transaction.  This
               is done for use within performance and scalability reasons, and for
               transactional reasons, such that the SSP's networks.
                   This will allow internal signaling elements set of provisioning
               actions either fail or succeed atomically, as a complete
               set.

3.2.  Category: Interconnect Schemes

   UC INTERCONNECT #1  Inter-SSP SED: SSPs create peering relationships
                       with other SSPs in order to establish sessions intended for this end-user.  The
                   provisioned SED is only distributed to specific local
                   data repositories,
                       interconnects.  Establishing these interconnects
                       involves, among other things, communicating and will probably differ from
                       enabling the
                   SED provisioned for use by signaling elements from points of ingress and other SSPs.

   UC SED DATA #3  Selective peering: While an SSP may provision used
                       to establish sessions to a set of public
                       identifiers.

   UC INTERCONNECT #2  Direct vs Indirect Peering: Some inter-SSP
                       peering relationships are created to enable the
                   same SED records
                       establishment of sessions to the public
                       identifiers for all other SSPs, which an SSP may also
                   wish is the carrier-of-
                       record.  This is referred to provision different SED records for different
                   SSPs (e.g., if they have different as direct peering.
                       Other inter-SSP peering
                   agreements).

   UC SED DATA #4  LUF-only data: An SSP can choose relationships are created
                       to provison LUF-only
                   data in enable the registry.  A querying SSP that receives
                   LUF-only data may need establishment of sessions to rely on other mechanisms
                   (e.g., [RFC3263] public
                       identifiers for domain-name based LUF) to obtain
                   LRF information.

   UC SED DATA #5  LUF and LRF data: An SSP can provison LUF- and LRF-
                   data in the registry.  In such cases, the querying which an SSP does not have is a transit
                       provider.  This is referred to rely on mechanisms such as DNS
                   (e.g., [RFC3263]) for routing information.

   UC SED DATA #6  Target Domain indirect
                       peering.  Some SSPs take into consideration an
                       SSP's role as a resolvable Domain Name,
                   administrative domain name, transit or both: The target
                   domain pertaining carrier-of-record
                       provider when selecting a route to a public identity or TN Range
                       identifier.

   UC INTERCONNECT #3  Intra-SSP SED: SSPs support the establishment of
                       sessions between their own public identifiers,
                       not just to other SSPs public identifiers.
                       Enabling this involves, among other things,
                       communicating and enabling intra-SSP signaling
                       points and other SED that can either be a DNS-resolvable domain name (i.e., via
                   [RFC3263]) or an administrative domain.  An differ from inter-
                       SSP may
                   also wish signaling points and SED.

   UC INTERCONNECT #4  Selective Peering (a.k.a. per peer policies):
                       SSPs create peering relationships with other SSPs
                       in order to provision both sets establish interconnects.  However,
                       SSPs peering relationships often result in
                       different points of data, and the
                   response is based on a default choice ingress or the querying
                   entity.

   UC other SED DATA #7  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
                       same set of scope for this document.

   UC SED DATA #8 public identifiers.

   UC SED DATA #9  EDITOR's NOTE: This use case seems to be a special
                   case INTERCONNECT #5  Provisioning of LUF-only provisioning.  Thoughts?

                   Provision an authoritative a delegated 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 a
                       registry to direct queries for the SSPs SSP's numbers
                       to the Tier 2. 2 name server.  Usually queries to
                       the registry should return NS records, but, 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.

3.1.1.3.

3.3.  Category: Data Aggregations SED Exchange and Discovery Models

   UC DATA SED EXCHANGE #1  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, Exchange and hence similar (or identical) SED
               records, provisioning the same set Discovery using unified LUF/LRF:
                       When establishing peering relationships some SSPs
                       wish to communicate or receive points of ingress
                       and other 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. that contain LUF and LRF.

   UC DATA SED EXCHANGE #2  Aggregation of  SED records: A complete set of session
               establishment data Exchange and Discovery using LUF's Domain
                       Name: When establishing peering relationships
                       some SSPs may consist of more than just one SED
               record.  To be able not wish to create communicate or receive
                       points of ingress 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.

3.1.1.4.  Category: Administration

   UC ADMIN #1  New authoritative additions: An SSP provisions a public
                identity or TN Range, as its authoritative entity (i.e.,
                carrier-of-record).

   UC ADMIN #2  New non-authoritative additions: An SSP 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 using the provisioned data to route.

             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 other SED using a
             recipient SSP who provides access registry.
                       They wish to these identities only communicate or receive domain
                       names resolvable 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 [RFC3263], and the route
             group associated with this DG needs to contain query
                       will then return the RN

   UC NP #2  Authoritative release: A release command associated with
             one or more public identities (or TN Ranges) is received
             from an authoritative entity indicating his relinquishing points of authoritative "ownership" over ingress or other
                       SED that form the respective
             identities.

             EDITOR's NOTE: Can't this be achieved by an authoritative
             disassociation? LUF.

   UC NP SED EXCHANGE #3  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,  SED Exchange and a release has Discovery using LUF's
                       Administrative Domain Identifier: When
                       establishing peering relationships some SSPs may
                       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 #1  Global TN destinations: The SSP wishes wish to add or remove one communicate or multiple fully qualified TN destinations in receive points of
                       ingress and other SED using a single
             provisioning request.

   UC ID #2  TN range destinations: The SSP wishes registry.  They
                       wish to add or remove one only communicate or multiple TN range destinations in a single provisioning
             request.  TN ranges support number ranges that need receive an
                       administrative domain identifier, which is not be
             'blocks'.  In
                       necessarily resolvable via DNS.  The subsequent
                       process of using that administrative domain
                       identifier to select points of ingress or other words the TN range 'start'
                       SED can be any
             number SSP specific and occurs outside the TN range 'end' can be any number that is
             greater than the TN range 'start'.
                       context of this protocol.

   UC ID #3  Non-TN destinations: An SSP chooses to peer their messaging
             service with another SED EXCHANGE #4  Co-existent SED Exchange and Discovery Models:
                       When supporting multiple peering relationships
                       some SSPs picture/video mail service.
             Allowing a user have the need to send concurrently support
                       all three of the SED Exchange and receive pictures and/or video
             messages to a mobile user's handset, Discovery
                       Models described above, for example.  The
             important aspect the same set of this use case is that it goes beyond
             simply mapping TNs to IP addresses/hostnames that describe
             points-of-interconnect
                       lookup keys.

3.4.  Category: SED Record Content

   UC SED RECORD #1  SED Record Content: Establishing interconnects
                     between peering network SSP's.
             Rather, for each user the SSP provisions SSPs involves, among other things,
                     communicating points of ingress, the subscriber's
             email address (i.e. jane.doe@example.com).  This mapping
             allows service types
                     (SIP, SIPS, etc) supported by each point of
                     ingress, and the mobile multimedia messaging relative priority of each point of
                     ingress for each service center
             (MMSC) type.

   UC SED RECORD #2  Time-To-Live (TTL): For performance reasons,
                     querying SSPs sometimes cache SED that had been
                     previously looked up for a given public identity.
                     In order to use the subscriber email address as accomplish this, SSPs sometimes specify
                     the lookup
             key TTL associated with a given SED record.

3.5.  Category: Separation and route messages accordingly. Facilitation of Data Management

   UC ID #4 DATA #1  Separation of responsibility: Provisioning Responsibility: An SSP's
               operational practices can seperate often separate the responsibility
               of provisioning the routing information, points of ingress and other SED, from
               the associated identities, to
             different entities. responsibility of provisioning public identifiers (or
               TN ranges or RNs).  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,
               subscriber, the SSP's back office system provisioning systems provisions the
               associated public identities. identifiers.

   UC 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 DATA #2  Destination Groups: SSPs often provision identical SED
               for large numbers of public identifiers.  Groups of
               public identifiers that have the offered SSP.  An SSP receiving a peering offer should
             be able to accept or decline the offer.  If the offer same SED are created.
               This grouping is
             rejected the registry should not provision corresponding know as Destination Group.  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 then
               indirectly associated with that are provisioned group rather than to their local
             data repositories.

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: each
               individual public identities, destination groups,
           routing groups identity.

   UC DATA #3  Route Groups: SSPs often provision identical SED for
               large numbers of public identifiers, and data recipient groups.

   DREQ2:  The registry provisioning data model MUST support the
           grouping then expose that
               relationship between a group of SED records and aggregation a group
               of public identities within
           destination groups.

   DREQ3:  The registry provisioning data model SHOULD support the identifiers to one or more SSPs.  This combined
               grouping of SED records and aggregation Destination Groups
               facilitates management of TN Ranges within destination
           groups.

   DREQ4:  The registry provisioning data model SHOULD support public identity SED
               relationships and the
           grouping list of peers (data recipients)
               that can lookup those public identifiers and aggregation receive that
               SED.  This dual set of RNs within destination groups.

   The following functional requirements apply:

   FREQ1:   The registry provisioning interface MUST support the
            creation SED Records and Destination Groups
               is termed as a Route Group.

3.6.  Category: Lookup Keys

   UC LOOKUP #1  Additions and deletions: SSPs often allocate and deletion of: de-
                 allocate specific public identities, destination
            groups, routing groups identifiers to and data recipient groups.

   FREQ2:   The registry provisioning interface MUST support near-real-
            time, non-real-time from end-
                 users.  This involves, among other things, activating
                 or deactivating specific public identifiers (or TN
                 ranges or RNs), and deferred provisioning operations.

   FREQ3:   The registry provisioning interface MUST support directly (or indirectly)
                 associating them with the
            following types of modifications:

            - reassignment appropriate points of one or more public identities from one
            destination group ingress
                 and other SED.

   UC LOOKUP #2  Carrier-of-Record vs Transit Lookup Key Provisioning:
                 Some inter-SSP peering relationships are created to another;

            - reassignment
                 enable the establishment of one data recipient from one destination
            group sessions to another;

            - association and disassociation the lookup keys
                 for which an SSP is the carrier-of-record.  Other
                 inter-SSP peering relationships are created to enable
                 the establishment of sessions to lookup keys for which
                 an SSP is a "Default Routing
            Group" with transit provider.  Some SSPs take into
                 consideration an SSP's role as a Data Recipient; and,

            - identification of transit or carrier-of-
                 record provider when selecting a destination group route to a public
                 identifier.

   UC LOOKUP #3  Multiplicity of Identical Lookup Keys: As described in
                 previous use cases, SSPs provision lookup keys and
                 their associated SED for multiple peering SSPs, and as
                 both the carrier-of-record and transit provider.  As a "Carrier of
            Record" (COR) destination group or
                 result, a "Transit" given lookup key can reside in multiple
                 destination
            group.

   FREQ4:   When an entity groups at any given time.

   UC LOOKUP #4  Lookup Key Destination Group Modification: SSPs often
                 change the SED associated with a given lookup key.
                 This involves, among other things, directly or
                 indirectly associating them with a different client identifier than that point of
                 ingress, different services, and/or different other
                 SED.

   UC LOOKUP #5  Lookup Key Carrier-Of-Record vs Transit Modification:
                 SSPs may have the carrier need to change their Carrier-Of-
                 Record vs Transit role for lookup keys they previously
                 provisioned.

   UC LOOKUP #6  Modification of record authority: An SSP indicates that it is
                 the carrier-of-record for a an existing public identity in a
            destination group adds a new SSP to a destination recipient
            group
                 or TN Range.  If the public identity or TN Range was
                 previously associated with that destination group, the registry
            provisioning interface MUST: a different carrier-of-
                 record then there are multiple possible outcomes, such
                 as: a) notify the new SSP of the
            updated routing information (which constitutes a peering
            offer) previous carrier-of-record is disassociated,
                 b) not provision the SED previous carrier-of-record is relegated to
                 transit status, or c) the new SSP's LDR unless
            the new SSP signals acceptance.

   FREQ5: carrier-of-record is
                 placed in inactive mode.  The registry provisioning interface MUST separate choice may be dependent
                 on the
            provisioning deployment scenario, and is out of the scope for
                 this document.

3.7.  Category: Number Portability

   UC NP #1  EDITOR's NOTE: Need to clarify this further.

             The SSP wishes to provide in query response to public
             identifiers an associated routing information from number or RN.  This is
             the associated
            identities.

   FREQ6:   The registry provisioning protocol MUST define case when 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 public identifiers is no longer
             associated with original SSP but have been ported to
            define multiple sub-identities that can be used in data a
             recipient groups

   FREQ8:   The registry provisioning interface MUST define the
            concurrency rules, locking rules, and race conditions that
            underlie SSP who provides access to these identifiers via
             a switch on the implementation of that protocol operation and
            that result from SS7 network identified by the coexistence of protocol operations that
            can operate on multiple objects in RN.  In this
             case a single operation and
            bulk file operations destination group containing all numbers that may process for an extended period
            of time.

   FREQ9:   The registry provisioning interface MUST support should
             be routed to this RN needs to be created and the ability
            for a Data Recipient route
             group associated with this DG needs to optionally define a Routing Group as
            their Default Routing Group, such that if contain the RN

3.8.  Category: Misc

   UC MISC #1  Data Recipient
            performs a resolution request Offer and the lookup key being
            resolved Accept: When a peering
               relationship is not found established (or invalidated) SSPs
               provision (or remove) data recipients in the Destination Groups visible registry.
               However, a peer may first need to accept it's role (as a
               data recipient) before such a change is made effective.
               Alternatively an auto-accept feature can be configured
               for a given data recipient.

   UC MISC #2  Open numbering plans: In several countries, an "open
               numbering plan" is used, which is such that Data Recipient then the SED Records associated with the
            Default Routing Group shall be returned carrier-
               of-record does not in fact know the resolution
            response.

   FREQ10:  The registry provisioning interface MUST support the ability
            for the owner of complete number, but
               instead only knows 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 portion of the ability to specify zero or more E.164 number.  The
               rest of the following in
            association with digits are handled by a given Routing Group: Resolution Client IP
            Address(es) or Domain Names, Calling Party URI(s).  The
            result will be PBX off of that
               carrier-of-record, and even the resolution server would evaluate the
            characteristics number of those digit is
               not fixed.  For example, an SSP can be the Source, compare them against Source
            Based Routing Criteria associated with carrier-of-
               record for "+123456789", and is also the Routing Groups
            visible to carrier-of-
               record for every possible expansion of that Data Recipient, number such
               as "+12345678901" and return any SED Records
            associated with "+123456789012", even though the matching Routing Groups.

   FREQ11:  The registry provisioning interface MUST track, via a client
            identifier,
               SSP does not know what those expansions could be, because
               the entity provisioning each data object (e.g.
            Destination Group or Routing Group ). PBX decides that.  This client
            identifier will identify can be described as the entity that is responsible
               carrier-of-record effectively being authoritative for
            that data object from a protocol interface perspective.
               "prefix".

4.  Requirements

   This client identifier SHOULD be tied to Section lists the session
            authentication credentials that requirements based on the client uses to connect
            into to use cases in
   Section 3.  Unless explicitly stated as optional, the registry.

            The registry
   provisioning interface MUST incorporate a data
            recipient identifier that identifies the organization
            responsible must support these requirements.

   REQ1:   a) Real-time, b) non-real-time bulk, and c) multi-request
           provisioning.

   REQ2:   Inter-SSP SED with support for each data object from direct and indirect peering.

   REQ3:   Intra-SSP SED.

   REQ4:   Selective peering.

   REQ5:   Provisioning of a business
            perspective.  This organization identifier may or may not
            ultimately refer to delegated name server.

   REQ6:   The following SED Exchange and discovery models (concurrently
           for the same organization that public identifier): a) unified LUF/LRF, b) LUF-
           only with domain name, and c) LUF-only with administrative
           domain.

   REQ7:   Provisioning of SED Record content

   REQ8:   (Optional) Communicate the client
            Identifier refers to.  The separation TTL for a given SED Record.

   REQ9:   Separation of responsibility of provisioning the data recipient
            identifier points of
           ingress and other SED, from the client identifier will allow for the
            separation responsibility of
           provisioning public identifiers.

   REQ10:  Additions and deletions of public identifiers, TN ranges and
           RNs.

   REQ11:  Provisioning of, and modifications to, the two entities, when following
           aggregations: destination group and route groups.

   REQ12:  Support the need arises.

            Exactly one client identifier MUST be allowed to provision
            objects under distinction between an SSP as a given data recipient identifier.  But carrier-of-record
           provider versus transit provider.

   REQ13:  Support for lookup keys having identical business keys (the
           public identity string, the digits that comprise an RN, the
           start and end point of a
            client identifier MUST be allowed to provision objects under TN range's range) that concurrently
           exist across multiple data recipient identifiers.

            Objects provisioned under one "Protocol Client Identifier"
            MUST NOT destination groups and where each
           destination group may be alterable managed by a provisioning session established different SSPs.

           Editor's note: We need to simplify the above requirement.

   REQ14:  Modification of lookup keys by another "Protocol Client Identifier".

   FREQ12:  The registry provisioning protocol MUST allow allowing them to be moved to a
           different destination group via an SSP atomic operation.

   REQ15:  SSPs to
            provision LUF-only or LUF+LRF data in change their Carrier-Of- Record vs Transit role.

   REQ16:  Support for modification of authority with the registry via a
            single provisioning interface conditions
           described in UC LOOKUP #6.

   REQ17:  Destination group offer and data model.

4. acceptance (optionally support
           auto-acceptance).

   REQ18:  Open numbering plans.

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

6.  IANA Considerations

   This document does not register any values in IANA registries.

6.

7.  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 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.), Hadriel
   Kaplan (Acme Packet) and other participants on the DRINKS mailing
   list.

7.

8.  References

7.1.

8.1.  Normative References

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

7.2.

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

   [RFC5067]  Lind, S. and P. Pfautz, "Infrastructure ENUM
              Requirements", RFC 5067, November 2007.

   [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