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

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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 May 8, 2009.

Abstract

This document presents use cases that illustrate what constitutes session establishment data, the functional components that need them, and the protocol requirements for provisioning and managing session establishment data within the identified functional components.

Table of Contents

1.  Introduction
2.  Terminology
3.  Use Cases
    3.1.  Provisioning a Registry
    3.2.  Provisioning an ENUM Server
    3.3.  LRF and LUF
        3.3.1.  LRF
        3.3.2.  LUF
    3.4.  SSP
        3.4.1.  Generic SSP
        3.4.2.  Small SSP
        3.4.3.  Large SSP
    3.5.  Miscellaneous Use Cases
        3.5.1.  Separation of Responsibility
        3.5.2.  Intra-Network vs Inter-Network
        3.5.3.  Massive Sunrise Provisioning
        3.5.4.  Real-Time Provisioning
        3.5.5.  Establishing Destination Groups
        3.5.6.  Direct and Selective Peering
        3.5.7.  Indirect Peering to Selected Destinations
        3.5.8.  Global TN Destinations
        3.5.9.  TN Range Destinations
        3.5.10.  RN Destinations
        3.5.11.  Non-TN Destinations
        3.5.12.  Peering Relationship Management
        3.5.13.  Peering Grant/Acceptance
        3.5.14.  Points of Egress
        3.5.15.  Tier 2
        3.5.16.  Non-blocking transactions
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgments
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

This document captures the use cases that have been proposed so far within the DRINKS requirements design team. The goal is to seek working group feedback to identify a set of in-scope use cases. The end result of the use cases is to identify the data model and requirements for provisioning and managing session establishment data.

2.  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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This document also reuses the SIP terminology defined in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). The Lookup Function (LUF), Location Routing Functions (LRF) and other session peering terms are defined [I‑D.ietf‑speermint‑terminology] (Malas, D. and D. Meyer, “SPEERMINT Terminology,” November 2008.). In addition, this document specifies the following additional terms.

Destination Group:

a set of global telephone numbers, telephone number ranges, dial codes, or other public identifiers that are grouped together to facilitate session setup and routing.

Public Identity:

a generic term that refers to a telephone number(TN), a range of TNs, 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, sip:paul.speermint@example.com).

Routing Group:

a logical grouping of routes. A Destination Group may be associated with one or more routing groups based on its association with the data recipient group.

Data Recipient Group:

a list of SIP Service Providers (SSPs) that have access to the associated Destination Group data.

3.  Use Cases

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 Section 3.5 (Miscellaneous Use Cases).

3.1.  Provisioning a Registry

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:

1. Provisioning destination groups and associated routing information.
2. Provisioning data recipient groups.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.

3.2.  Provisioning an ENUM Server

This Section targets use cases concerned with the provisioning of session establishment data in the ENUM Server. The following use cases have been proposed:

1. Provisioning a Public Identify or set of Public Identities at an effective date/time.
2. A Public Identify is taken out of service at an effective date/time.
3. Assigning a set of Public Identities to a different destination group, thereby changing their routing.

3.3.  LRF and LUF

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

3.3.1.  LRF

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. Roaming mobile user uses IMS service accessed through local breakout, the service is located outside the serving network.
9. 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.
10. 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.
11. 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.
12. 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.
13. The service provider may have fixed domain routing specified in the LRF which overrides the domain routing provided by peer networks.
14. 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.

3.3.2.  LUF

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?}

3.4.  SSP

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

3.4.1.  Generic SSP

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.

3.4.2.  Small SSP

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.

3.4.2.1.  Configuring small SSP routing

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.

3.4.2.2.  Small SSP LUF/LRF consolidation

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.

3.4.3.  Large SSP

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

3.4.3.1.  Configuring large SSP routing

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.

3.4.3.2.  Large SSP LUF/LRF separation and LRF distribution

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.

3.4.3.3.  Large SSP peering with a small SSP

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.

3.5.  Miscellaneous Use Cases

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.

3.5.1.  Separation of Responsibility

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.

3.5.2.  Intra-Network vs Inter-Network

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.

3.5.3.  Massive Sunrise Provisioning

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.

3.5.4.  Real-Time Provisioning

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.

3.5.5.  Establishing Destination Groups

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.

3.5.6.  Direct and Selective Peering

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.

3.5.7.  Indirect Peering to Selected Destinations

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.

3.5.8.  Global TN Destinations

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

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

3.5.10.  RN Destinations

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

3.5.12.  Peering Relationship Management

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.

3.5.13.  Peering Grant/Acceptance

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.

3.5.14.  Points of Egress

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.

3.5.15.  Tier 2

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.

3.5.16.  Non-blocking transactions

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 .

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 (Verisign), Manjul Maharishi (Verisign), Penn Pfautz (AT&T Corp), the co-chairs (Richard Shockey, Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of this document.

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.