DRINKS Use cases and Protocol Requirements

This Section contains the use cases presented so far. The use cases are logically grouped into functional areas: provisioning a registry, provisioning an ENUM server, LRF & LUF, and SIP Service Provider (SSP). Use cases that are are not presently grouped are specified in .

This Section targets use cases concerned with the provisioning of session establishment data in the registry. Provisioning can be accomplished in (near) real time through an automated interface (e.g., from a service provisioning system) or by specifying an effective date and time. When an effective date/time is used, the registry validates the format and enters it into the registry database with the effective date & time. The following use cases are considered: Provisioning destination groups and associated routing information. Provisioning data recipient groups. Provisioning a public identity or identities (including a range of TNs): A globally routable TN or another type of public identity is provisioned and assigned to a Destination Group. No effective date is provided as it is desired to be made effective in (near) real time meaning as soon as validations (format) are complete, the data is entered into the Registry database. A distribution function may pick up the provisioned instance in real-time or in batch mode to distribute to each address server. Note that it is assumed that the routing information for the Destination Group has already been defined. This is another Use Case. A public identity (including a TN, or a TN range) is provisioned with an effective date & time. After format validations, the data is entered into the Registry database with the effective date & time. Upon reaching the effective date/time, the public identity will be distributed with the next distribution process. Public Identity is taken out of service: A public identity (including a TN, 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 may also trigger a number of delete updates during the distribution operations to appropriate deletes to each address server. Assigning a set of TNs to a different Destination Group changing their routing: A set of public identities (e.g., set of TNs) are assigned a different Destination Group which effectively changes their routing information. This may be due to a network re-arrangement, a Signaling path Border Element being split into two, or a need to do maintenance, two carriers merging, or other considerations. This scenario can also include an effective date and time. 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 action effectively changes the routing for all public identities and associated services to the routing information associated with the new Data Recipient Group and Destination Group. Defining a Routing Group: A Routing Group is a set of routes that may include routes for a number of different public identities, e.g., TNs, IM identifier, email. A Destination Group may be associated with one or more Routing Groups.

This Section targets use cases concerned with the provisioning of session establishment data in the ENUM Server. The following use cases have been proposed: Provisioning a Public Identify or set of Public Identities at an effective date/time. A Public Identify is taken out of service at an effective date/time. Assigning a set of Public Identities to a different destination group, thereby changing their routing.

This Section contains use cases related to LRF and LUF. They are presented in the following sub-sections.

Source service provider direct connection (bi-lateral): A service provider may be connected directly with a peer network hosting the ultimate SIP destination. The source service provider is able to translate the information provided by the LUF to obtain the ingress point to the network containing the ultimate destination. Source service provider direct connection (bi-lateral): A service provider may be connected directly with a peer network hosting the SIP destination. The source service provider is not able to translate the information received from the LUF to an ingress point for the network containing the ultimate destination. Source service provider direct connection (bi-lateral): A service provider may be connected directly with a peer network not hosting the SIP destination. The Source service provider is not able to translate to the ultimate destination because the LUF does not contain a translation. The selected target network is able to perform the LUF to identify the ultimate destination. Source service provider is not connected directly with a peer network hosting the ultimate SIP destination rather through an intermediate transit network which is connected to a peer network hosting the ultimate SIP destination. Note that variations in use cases 1, 2 & 3 all apply. Source service provider is not connected directly with a peer network hosting the ultimate SIP destination, rather to a clearing house network which is connected to a peer network hosting the ultimate SIP destination. Source service provider is not connected directly with a peer network hosting the ultimate SIP destination rather through more than one intermediate transit networks which are all connected to a peer network hosting the ultimate SIP destination. The source service provider has to chose the transit service provider to select. Source service provider has multiple paths to a destination network both on inter-network connections and inter-transit network connections. The source service provider wants to select different transit networks and different routes to those networks based on various criteria such as traffic load, capacity, cost, latency, etc. Roaming mobile user uses IMS service accessed through local breakout, the service is located outside the serving network. Roaming mobile user is disconnected from emergency service call (via IMS local breakout). The PSAP is located in a network outside of the serving network. The PSAP initiates a callback to the mobile which should go to the serving network, not the home network from the network the PSAP is located in. A transit network connected to the source service provider has had a route change or a network connectivity change which needs to be communicated to its peer networks. A transit network has a change in the domains it is able to reach (added, dropped/unavailable, route change) which it needs to send to its peer networks. The transit network uses LRF to route internally to the network and to select one of several possible exit points, next hop transit network and specific connection between networks. The service provider may have fixed domain routing specified in the LRF which overrides the domain routing provided by peer networks. The service provider may have fixed routing specified in the LRF as a default until a peer network identifies it is able to provide alternate (better) routing.

A service provider's LUF is connected to several different Registries some for national numbers, some for enterprise identifiers (e.g. @example.com translating to @example.nt for an enterprise user who has a mobile with a public user identity or GRUU (3GPP TS 23.228) which is part of an enterprise domain. {What if there is a collision and conflict between some particular number or domain between registries?}

This Section contains SIP Service Provider specific use cases. They are presented in the following sub-sections.

An SSP provisions a registry to offer different routes to different interconnecting parties. The SSP uses the same routes for an aggregation of public identities (e.g., TNs) and desires to be able to specify routing for the aggregate. Routes consist of a set of RRs of any legitimate type.

The small SSP provides coverage to a small city only with 3 different peer interconnects: 1) To another small SSP covering an adjacent small city; 2) to a mid-sized SSP providing coverage to the remainder of the state; 3 to a large multi-national SSP providing SSP transit services for the remainder of the world.

The small SSP with a small number of SSP peer arrangements prefers to statically define and provision the SED routing through network engineering tools by the network engineering staff. This is because the domain coverage of each peer SSP will not change very frequently and the small SSP does not want to incur the cost and complexity of a dynamically established routing data.

A small SSP only needs a single network element to handle its entire LUF/LRF needs and as such combines the LUF and LRF. The routing associations in this network element are provisioned statically through network management tools by network operation or engineering staff.

The large SSP provides coverage to a large country: the SSP is administratively divided into regions. The SSP provides SSP transit services to smaller SSPs operating in the same areas. The SSP has both direct SSP connections for national and international service and indirect SSP connections for international service to some countries based on traffic levels. This results in multiple possible routes to some destination SSPs through different intermediate SSPs. Each SSP region has a different sub-set of peer SSPs that it is directly connected to (e.g. Some regions may have to route internally to another SSP region to reach the destination SSP).

The large SSP has a large number of direct and indirect peer arrangements along with multiple possible routes to the same destination SSP. The large SSP prefers to only provision the SSP peers and have the elements such as SBCs learn the routes based on peer SSP advertisements to eliminate routing errors (loops, dead ends, etc.) which are service affecting and almost impossible to troubleshoot in a network of this size.

A large SSP needs to centralize its LUF but split off the LRF for deployment in decentralized regional network elements. The routing associations in the regional LRFs are provisioned dynamically through advertisements by the large SSP peering SSPs regarding which domains they are able to handle.

A large SSP peers with a small SSP. The small SSP is unable to support the cost and complexity of dynamically advertising to its peer SSPs the domains it is able to reach directly or indirectly. The large SSP provisions routing association data statically representing the domains which the small SSP can reach either directly or indirectly, through network management tools by network operation or engineering staff.

This Section contains all the use cases that were not categorized as belonging to the specific groups indicated above. Based on further discussions these may be re-classified.

An SSP's business practices are such that; (i) network engineering and planning personnel are responsible for provisioning the points of interconnect (e.g. hosts and IP addressing information), and (ii) back office systems are responsible for number management provisioning of TNs. An example flow would be: a network engineer establishes physical interconnect with a peering SSP's network and provisions associated domain name, host, and IP addressing information, which is provisioned to the registry/ENUMserver. Separately, for each new service subscription, the SSP's back office system provisions the associated TNs or other public identities.

SSP wishes to provision their intra-network Session Establishment Data (SED) such 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 CMS (calling) to discover another (called). The SSP provisions IP addressing information of each CMS, which is provisioned to the registry/ENUMserver but only distributed to their own local ENUM server. This SED may differ from the SED that is distributed to other local ENUM servers.

Based on configurable thresholds, sunrise may imply a batch asynchronous provisioning process. For instance, an SSP has commissioned a new ENUM server and wishes to download a very large number of telephone numbers. Rather than stream individual TNs in real-time, one at a time, towards the ENUM server the SSP's back-office system prefers to perform the operation as a set of one or more batches. The SSP has just commissioned a new ENUM server which they plan to employ as a centralized routing server. The network engineering group has provisioned, upon their ENUM server, the IP addressing information of all CMS which constitute the SSP's topology. During a regularly scheduled maintenance window the SSP would like to download from its back office system the TNs associated with each CMS.

Post-sunrise, an SSP wishes to have their back-office systems add or remove TNs per normal business operations. Over the course of a day there is churn in the SSP's subscriber base and as such they would like the ability to stream, in real-time, additions, modifications and deletions.

An SSP wishes to control the flow of traffic into their network (ingress) based on groupings of Public Identities, called Destination Groups. Associating each group of Public Identities with a specific set of ingress SBEs or points-of-interconnect. The SSP, for example, sub-divides the country into four regions: North-East, South-East, Mid-West, and West-Coast. For each region they establish points-of-interconnect with peers and provision the associated SED hostnames or IP addresses of the SBEs used for ingress traffic. Against each region they provision the served Public Identities in to the Destination Groups and associate those destination groups with the appropriate points of ingres. The destination groups and points of ingress are provisioned to the Registyr/Enumserver. Need to separate this use case into two.

In this case the SSP is the actual carrier-of-record; the entity serving the end user. And the SSP wishes to communicate different SED data to some of its peers that wish to route to its destinations. So the SSP has implemented direct points-of-interconnect with each peer and therefore would like address-resolution to result in different answers depending on which peer is asking.

The SSP transit provider wishes to provide transit peering points for a set of destinations. But that set of destinations does not align with the destination groups that already exist. The SSP wishes to establish its own destination groups for the destinations that it provides transit to.

The SSP wishes to add or remove one or multiple fully qualified TN destinations in a single provisioning request.

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.

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.

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.

An SSP wishes to have the peering relationship management process factilitated through automation. An SSP can offer itself as a Peer to another SSP and that peer can accept or reject that peering relationship.

An SSP wishes to facilitate the establishment of peering relationships and interconenct points with its peers. It submits a grant to a potential peering partner for a point of interconnect. The Grantee can accept or ignore the grant. The act of granting and accepting is facilitated by an automation process.

An SSP has a peering relation ship with a peer. And when sending messages to that peer's point of interconnection, the originating SSP wishes to egress through one or more points of egress. These points of egress may vary for an given peer.

An SSP maintains a Tier 2 name server that contains the NAPTR records that constitute the terminal step in the LUF. The SSP needs to provision an registry to direct queries for the SSPs numbers to the Tier 2. Usually queries to the registry should return NS records, but, in cases where the Tier 2 uses a different domain suffix from that used in the registry, CNAME records may be employed instead.

An SSP is loading a large update in the registry (for example, a large amount of add and delete operations due to a Destination Group being split into 2). In the meantime, the SSP wants to change a route linked with another Destination Group because it has been misconfigured .