draft-ietf-drinks-usecases-requirements-00.txt   draft-ietf-drinks-usecases-requirements-01.txt 
DRINKS S. Channabasappa, Ed. DRINKS S. Channabasappa, Ed.
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Informational May 27, 2009 Intended status: Informational March 8, 2010
Expires: November 28, 2009 Expires: September 9, 2010
DRINKS Use cases and Protocol Requirements DRINKS Use cases and Protocol Requirements
draft-ietf-drinks-usecases-requirements-00 draft-ietf-drinks-usecases-requirements-01
Abstract
This document captures the use cases and associated requirements for
interfaces to provision session establishment data into SIP Service
Provider components that aid 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 28, 2009. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document captures the use cases and associated requirements for described in the BSD License.
interfaces to provision session establishment data into SIP Service
Provider components that aid with session routing. Specifically, the
current version of this document focuses on the provisioning of one
such element, termed the registry.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 10 3. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 10
3.1. Registry Provisioning . . . . . . . . . . . . . . . . . . 10 3.1. Registry Provisioning . . . . . . . . . . . . . . . . . . 10
3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 14 3.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 15
3.2. Distribution of data into local data repositories . . . . 17 3.2. Distribution of data into local data repositories . . . . 18
3.3. Miscellaneous Use Cases . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
3.3.1. Indirect Peering to Selected Destinations . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
3.3.2. TBD: RN Destinations . . . . . . . . . . . . . . . . . 17 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document reuses terms from [RFC3261] (e.g., SIP) and [RFC5486] This document reuses terms from [RFC3261] (e.g., SIP) and [RFC5486]
(e.g., LUF, LRF). In addition, this document specifies the following (e.g., LUF, LRF). In addition, this document specifies the following
additional terms. additional terms.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
o Local Data Repositories are the data store component of an o Local Data Repositories are the data store component of an
addressing server that provides resolution responses. addressing server that provides resolution responses.
o Registries are responsible for distributing SED and related o Registries are responsible for distributing SED and related
information to the local data repositories. information to the local data repositories.
In addition, this document proposes the following aggregation groups In addition, this document proposes the following aggregation groups
with regards to SED (certain use cases also illustrate these groups): with regards to SED (certain use cases also illustrate these groups):
o Aggregation of public Identifiers: The initial input "key" to a o Aggregation of public Identifiers: The initial input 'key' to a
SED lookup is a public identifier. Since many public identifiers SED lookup is a public identifier. Since many public identifiers
will share similar (or identical) destinations, and hence return will share similar (or identical) destinations, and hence return
similar (or identical) SED, provisioning the same set of SED for similar (or identical) SED, provisioning the same set of SED for
millions of public identifiers is inefficient, especially in cases millions of public identifiers is inefficient, especially in cases
where the SED needs to be modified. Therefore, an aggregation where the SED needs to be modified. Therefore, an aggregation
mechanism to "group" public identifiers is proposed. This mechanism to 'group' public identifiers is proposed. This
aggregation is called a "destination group". aggregation is called a 'destination group'.
o Aggregation of SSPs: It is expected that SSPs may want to expose o Aggregation of SSPs: It is expected that SSPs may want to expose
different sets of SED, depending on the receiving SSP. This different sets of SED, depending on the receiving SSP. This
exposure may not always be unique, in which case an aggregation exposure may not always be unique, in which case an aggregation
makes it efficient. Such an aggregation is proposed, and termed makes it efficient. Such an aggregation is proposed, and termed
"Data Receipient Group". 'Data Receipient Group'.
o Aggregation of SED records: Finally, it is anticipated that a o Aggregation of SED records: Finally, it is anticipated that a
complete set of routing data will consist of more than just one complete set of routing data will consist of more than just one
SED record. To be able to create and use the same set of SED SED record. To be able to create and use the same set of SED
records multiple times (without creating duplicates) an records multiple times (without creating duplicates) an
aggregation mechanism at this level is proposed, and called aggregation mechanism at this level is proposed, and called
"routing group". 'Routing Group'.
The above aggregations are illustrated in Figure 3. The above aggregations are illustrated in Figure 3.
+---------+ +--------------+ +---------+ +--------------+
| Data | |DATA RECIPIENT| | Data | 0..n 1 |DATA RECIPIENT|
|Recipient|----------->| GROUP | |Recipient|------------| GROUP |
+---------+ +------.-------+ +---------+ +------.-------+
^ 0..n |
| |
| |
1 |
+--------------+ +---------+ +--------------+ +---------+
| ROUTING | ------------->| SED | | ROUTING | ------------->| SED |
| GROUP | | Record | | GROUP | 1 0..n | Record |
+--------------+ +---------+ +--------------+ +---------+
^ ^ |0..n |0..n
| | | |
| | | |
+--------------+ | | |
----->| DESTINATION |<----- | | 1 |
| | GROUP | | | 1..n +--------------+ 0..n |
| +--------------+ | | ---------| DESTINATION |--------- |
| ^ | | | | GROUP | | |
| | | | | +--------------+ | |
| | | | | | | |
| | | | | 1..n| | |
+---------+ +---------+ +---------+ | | | | |
| RN | | TN | | Public |------- | | | |
| | | Range | |Identity | 1 | 1 | | 1 |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ |
| RN | | TN | | Public |-----
| | | Range | |Identity | 1
+---------+ +---------+ +---------+
Figure 3: Data Model Diagram Figure 3: Data Model Diagram
A description of the relationships follows: Additional clarifications follow:
- An RN is associated with one or more Destination Groups
- A TN Range object is associated with one or more Destination Group
- A Public Identity is associated with zero or more Destination
Group
- A Public Identity is associated with zero or more SED Records
- A Destination Group is associated with zero or more Routing
Groups.
- A Routing Group is associated with zero or more SED Records; - A routing group is associated with zero or more SED Records;
NAPTRs and other SED Record Types associated with Routes are not NAPTRs and other SED record types associated with routes are not
User or TN specific. For example the user portion of a NAPTR user or TN-specific. For example the user portion of a NAPTR
regex will be "\1". regular expression will be "\1".
- An Routing Group is associated with zero or more peering - A routing group is associated with zero or more peering
organizations to control visibility/access privs to that Routing organizations to control visibility or access privileges to that
Group and the Destination Groups they expose. routing group and the destination groups they expose.
- A Data Recipient Group is associated with (contains) zero or more - A data recipient group contains zero or more data recipients to
Data Recipients to facilitate the allocation of access privileges facilitate the allocation of access privileges to routing groups.
to Routing Groups.
3. Use Cases and Requirements 3. Use Cases and Requirements
This section presents the use cases and associated requirements. This section presents the use cases and associated requirements.
3.1. Registry Provisioning 3.1. Registry Provisioning
Registry is the authoritative source for session establishment data Registry is the authoritative source for session establishment data
(SED). The registry needs to be provisioned with this data to (SED). The registry needs to be provisioned with this data to
perform its function. This data includes: destination groups, perform its function. This data includes: destination groups,
routing groups and data recipient groups. It can also include RNs routing groups and data recipient groups. It can also include RNs
and TN Ranges. The following sub-sections illustrate the use cases and TN Ranges. The following sub-sections illustrate the use cases
and the requirements, respectively. and the requirements, respectively.
3.1.1. Use Cases 3.1.1. Use Cases
USE CASE #1 Near-real-time provisioning: The registry is The use cases are divided into the following categories - process,
provisioned with data that is not accompanied by an routing, identity, administration, and number portability.
effective date or time. In such cases, the registry
will validate the data and make it effective in near
real-time.
USE CASE #2 Non-real-time provisioning: The registry is provisioned 3.1.1.1. Category: Process
via an asynchronous provisioning process. For
instance, an SSP has commissioned a new registry and
wishes to download a very large number of telephone
numbers. Rather than stream individual entities, one
at a time, the SSP's back-office system prefers to
perform the operation as a set of one or more batches
(e.g., via an external data file), instead of the near-
real-time provisioning interface.
USE CASE #3 Deferred provisioning: The registry is provisioned with UC PROCESS #1 Near-real-time provisioning: The registry is
data that is accompanied by an effective date and time. provisioned with data that is not accompanied by an
In scenarios such as this, the registry will validate effective date or time. In such cases, the registry
the data and wait until the effective date and time to will validate the data and make it effective in near
make it effective. TBD: What happens if near-real time real-time.
data overrides data parked for later incorporation?
USE CASE #4 Intra-network SED: SSP wishes to provision their intra- UC PROCESS #2 Deferred provisioning with effective date/time: The
network Session Establishment Data (SED) such that it registry is provisioned with data that is accompanied
enables current and future network services to identify by an effective date and time. In scenarios such as
and route real-time sessions. For example, in the case this, the registry will validate the data and wait
of VoIP calls it allows one SoftSwitch (calling) to until the effective date and time to make it
discover another (called). The SSP provisions IP effective. TBD: What happens if near-real time data
addressing information pertaining to each SoftSwitch, overrides data parked for later incorporation?
which is provisioned to the registry but only
distributed to a specific local data repository. This
SED may differ from the SED that is distributed to
other local data repositories.
USE CASE #5 Destination Groups: An SSP may wish to control the flow UC PROCESS #3 Batch provisioning: The registry is provisioned via an
of traffic into their network (ingress) based on asynchronous provisioning process. For instance, an
groupings of Public Identities. Associating each group SSP has commissioned a new registry and wishes to
of Public Identities with a specific set of ingress download a very large number of telephone numbers.
SBEs or points-of-interconnect. The SSP, for example, Rather than stream individual entities, one at a time,
sub-divides the country into four regions: North-East, the SSP's back-office system prefers to perform the
South-East, Mid-West, and West-Coast. For each region operation as a set of one or more batches (e.g., via
they establish points-of-interconnect with peers and an external data file), instead of the near-real-time
provision the associated SED hostnames or IP addresses provisioning interface.
of the SBEs used for ingress traffic. Against each
region they provision the served Public Identities into
groups- termed Destination Groups - and associate those
destination groups with the appropriate points of
ingres.
USE CASE #6 Public Identity is taken out of service: A public 3.1.1.2. Category: Routing
identity (or a TN range) is taken out of service
because it is no longer valid. The Registry receives a
delete operation and removes the public identity from
its database. This can also trigger delete operations
to keep the local data repositories up-to-date.
USE CASE #7 Assigning a set of public identities to a different UC ROUTING #1 Intra-network SED: SSP wishes to provision their
Destination Group: A set of public identities are intra-network Session Establishment Data (SED) such
assigned a different Destination Group which that it enables current and future network services to
effectively changes their routing information. This identify and route real-time sessions. For example,
may be due to a network re-arrangement, a Signaling in the case of VoIP calls it allows one SoftSwitch
path Border Element being split into two, or a need to (calling) to discover another (called). The SSP
do maintenance, two carriers merging, or other provisions IP addressing information pertaining to
considerations. This scenario can also include an each SoftSwitch, which is provisioned to the registry
effective date and time. but only distributed to a specific local data
repository. This SED may differ from the SED that is
distributed to other local data repositories.
USE CASE #8 Moving an SSP from one Data Recipient Group to another: UC ROUTING #2 Support for destination groups: An SSP may wish to
An SSP would like to re-assign the Destination Groups control the flow of traffic into their network
it shares with a peer and move the peer SSP from one (ingress) based on groupings of Public Identities.
Data Recipient Group to another. This results in the Associating each group of Public Identities with a
moved peer seeing a new and different set of routing specific set of ingress SBEs or points-of-
data. 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
into groups- termed Destination Groups - and associate
those destination groups with the appropriate points
of ingres.
USE CASE #9 Inter-network SED (Direct and Selective Peering): In UC ROUTING #3 Modifying destination groups: A set of public
this case the SSP is the actual carrier-of-record; the identities are assigned a different Destination Group
entity serving the end-user. The SSP wishes to which effectively changes their routing information.
communicate different SED data to some of its peers This may be due to a network re-arrangement, a
that wish to route to its destinations. So the SSP has Signaling path Border Element being split into two, or
implemented direct points-of-interconnect with each a need to do maintenance, two carriers merging, or
peer and therefore would like address-resolution to other considerations. This scenario can also include
result in different answers depending on which peer is an effective date and time.
asking.
USE CASE #10 Separation of Responsibility: An SSP's operational UC ROUTING #4 Indirect Peering to Selected Destinations: The SSP
practices can seperate the responsibility of transit provider wishes to provide transit peering
provisioning the routing information, and the points for a set of destinations. But that set of
associated identities, to different entities. For destinations does not align with the destination
example, a network engineer can establish a physical groups that already exist. The SSP wishes to
interconnect with a peering SSP's network and provision establish its own destination groups for the
the associated domain name, host, and IP addressing destinations that it provides transit to. (Editor's
information. Separately, for each new service note: This use case needs more work.)
subscription, the SSP's back office system provisions
the associated public identities.
USE CASE #11 Global TN Destinations: The SSP wishes to add or remove UC ROUTING #5 Inter-network SED (direct and selective peering): In
one or multiple fully qualified TN destinations in a this case the SSP is the actual carrier-of-record; the
single provisioning request. entity serving the end-user. 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.
USE CASE #12 TN Range Destinations: The SSP wishes to add or remove UC ROUTING #6 Selecting egress points: An SSP has a peering
one or multiple TN Range destinations in a single relationship with a peer, and when sending messages to
provisioning request. TN Ranges support number ranges that peer's point of interconnection, the originating
that need not be 'blocks'. In other words the TN range SSP wishes to use one or more points of egress. These
start can be any number and the TN range end can be any points of egress may vary for an given peer. This
number that is greater than the TN range start. capability is supported by allowing an originating SSP
to provision SED for identities terminating to other
SSPs where the originating SSP is itself the data
recipient. The provisioning SSP may make use of
multiple data recipient identities if it requires
different sets of egress points be used for calls
originating from different parts of its network.
Routing from egress points to ingress points of the
terminating SSP may be accomplished by static routing
from the egress points or by the egress points using
data provisioned to the Registry by the terminating
SSP.
USE CASE #13 Non-TN Destinations: An SSP chooses to peer their UC ROUTING #7 SSP prefers to provision LUF and LRF data in the
messaging service with another SSPs picture/video mail registry: SSP prefers the registry to have access to
service. Allowing a user to send and receive pictures LUF and LRF information. In this case the originating
and/or video messages to a mobile user's handset, for SSP does not have to rely on mechanisms such as DNS
example. The important aspect of this use case is that (e.g., [RFC3263]) for routing information since a
it goes beyond simply mapping TNs to IP addresses/ registry query will return the terminating SBE.
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.
USE CASE #14 Tier 2 Name Server: An SSP maintains a Tier 2 name UC ROUTING #8 Provision an authoritative name server (not actual
server that contains the NAPTR records that constitute route): An SSP maintains a Tier 2 name server that
the terminal step in the LUF. The SSP needs to contains the NAPTR records that constitute the
provision an registry to direct queries for the SSPs terminal step in the LUF. The SSP needs to provision
numbers to the Tier 2. Usually queries to the registry an registry to direct queries for the SSPs numbers to
should return NS records, but, in cases where the Tier the Tier 2. Usually queries to the registry should
2 uses a different domain suffix from that used in the return NS records, but, in cases where the Tier 2 uses
registry, CNAME and NS records may be employed instead. a different domain suffix from that used in the
registry, CNAME and NS records may be employed
instead.
USE CASE #15 Peering Offer/Acceptance: An SSP offers to allow 3.1.1.3. Category: Identity
terminations from another SSP by adding that SSP to a
Data Recipient Group it controls. This causes
notification of the offered SSP. An SSP receiving a
peering offer should be able to accept or decline the
offer. If the offer is rejected the Registry should
not provision corresponding SED to the rejecting SSP.
It is expected that this capability will apply mainly
in the transit case where non-authoritative parties (in
the sense of not being the terminating SSP for an
identity) wish to offer the ability to reach the
identity and originating SSPs may wish to restrict the
routes that are provisioned to their local data
repositories.
USE CASE #16 Points of Egress: An SSP has a peering relationship UC ID #1 Deletion of public identity: A public identity (or a TN
with a peer, and when sending messages to that peer's range) is taken out of service because it is no longer
point of interconnection, the originating SSP wishes to valid. The Registry receives a delete operation and
use one or more points of egress. These points of removes the public identity from its database. This can
egress may vary for an given peer. This capability is also trigger delete operations to keep the local data
supported by allowing an originating SSP to provision repositories up-to-date.
SED for identities terminating to other SSPs where the
originating SSP is itself the data recipient. The UC ID #2 Global TN destinations: The SSP wishes to add or remove one
provisioning SSP may make use of multiple data or multiple fully qualified TN destinations in a single
recipient identities if it requires different sets of provisioning request.
egress points be used for calls originating from
different parts of its network. Routing from egress UC ID #3 TN range destinations: The SSP wishes to add or remove one
points to ingress points of the terminating SSP may be or multiple TN range destinations in a single provisioning
accomplished by static routing from the egress points request. TN ranges support number ranges that need not be
or by the egress points using data provisioned to the 'blocks'. In other words the TN range 'start' can be any
Registry by the terminating SSP. number and the TN range 'end' can be any number that is
greater than the TN range 'start'.
UC ID #4 Non-TN destinations: An SSP chooses to peer their messaging
service with another SSPs picture/video mail service.
Allowing a user to send and receive pictures and/or video
messages to a mobile user's handset, for example. The
important aspect of this use case is that it goes beyond
simply mapping TNs to IP addresses/hostnames that describe
points-of-interconnect between peering network SSP's.
Rather, for each user the SSP provisions the subscriber's
email address (i.e. jane.doe@example.com). This mapping
allows the mobile multimedia messaging service center
(MMSC) to use the subscriber email address as the lookup
key and route messages accordingly.
UC ID #5 LUF-only provisioning: SSP wants to provision the registry
for LUF lookup only and prefers LRF to be accomplished via
non-registry mechanisms. In this case the registry lookup
will return a domain name and the originating SSP will rely
on mechanisms such as ([RFC3263]) to obtain routing
information. This routing information is managed by the
(terminating) SSP, via DNS mechanisms.
3.1.1.4. Category: Administration
UC ADMIN #1 Moving an SSP from one data recipient group to another:
An SSP would like to re-assign the destination groups it
shares with a peer and move the peer SSP from one Data
Recipient Group to another. This results in the moved
peer seeing a new and different set of routing data.
UC ADMIN #2 Separation of responsibility: An SSP's operational
practices can seperate the responsibility of
provisioning the routing information, and the associated
identities, to different entities. For example, a
network engineer can establish a physical interconnect
with a peering SSP's network and provision the
associated domain name, host, and IP addressing
information. Separately, for each new service
subscription, the SSP's back office system provisions
the associated public identities.
UC ADMIN #3 Peering offer/acceptance: An SSP offers to allow
terminations from another SSP by adding that SSP to a
Data Recipient Group it controls. This causes
notification of the offered SSP. An SSP receiving a
peering offer should be able to accept or decline the
offer. If the offer is rejected the registry should not
provision corresponding SED to the rejecting SSP. It is
expected that this capability will apply mainly in the
transit case where non-authoritative parties (in the
sense of not being the terminating SSP for an identity)
wish to offer the ability to reach the identity and
originating SSPs may wish to restrict the routes that
are provisioned to their local data repositories.
3.1.1.5. Category: Number Portability
UC NP #1 The SSP does not wish to provision individual TNs, but
instead, for ease of management, wishes to provision
Routing Numbers (e.g., as in some number portability
implementations). Each RN effectively represents a set of
individual TNs, and that set of TNs is assumed to change
'automatically' as TNs are ported in and ported out. Note
that this approach requires a query to resolve a TN to an
RN prior to using the provisioned data to route.
3.1.2. Requirements 3.1.2. Requirements
The following data requirements apply: The following data requirements apply:
DREQ1: The registry provisioning data model MUST support the DREQ1: The registry provisioning data model MUST support the
following entities: public identities, destination groups, following entities: public identities, destination groups,
routing groups and data recipient groups. routing groups and data recipient groups.
DREQ2: The registry provisioning data model MUST support the DREQ2: The registry provisioning data model MUST support the
skipping to change at page 15, line 20 skipping to change at page 16, line 24
- reassignment of one or more public identities from one - reassignment of one or more public identities from one
destination group to another; destination group to another;
- reassignment of one data recipient from one destination - reassignment of one data recipient from one destination
group to another; group to another;
- association and disassociation of a "Default Routing - association and disassociation of a "Default Routing
Group" with a Data Recipient; and, Group" with a Data Recipient; and,
- identification of a destination group as a "Primary - identification of a destination group as a "Carrier of
Provider" destination group or a "Transit" destination Record" (COR) destination group or a "Transit" destination
group. group.
FREQ4: When an entity with a different client identifier than that FREQ4: When an entity with a different client identifier than that
of the carrier of record for a public identity in a of the carrier of record for a public identity in a
destination group adds a new SSP to a destination recipient destination group adds a new SSP to a destination recipient
group associated with that destination group, the registry group associated with that destination group, the registry
provisioning interface MUST: a) notify the new SSP of the provisioning interface MUST: a) notify the new SSP of the
updated routing information (which constitutes a peering updated routing information (which constitutes a peering
offer) b) not provision the SED to the new SSP's LDR unless offer) b) not provision the SED to the new SSP's LDR unless
the new SSP signals acceptance. the new SSP signals acceptance.
skipping to change at page 17, line 14 skipping to change at page 18, line 18
Exactly one client identifier MUST be allowed to provision Exactly one client identifier MUST be allowed to provision
objects under a given data recipient identifier. But a objects under a given data recipient identifier. But a
client identifier MUST be allowed to provision objects under client identifier MUST be allowed to provision objects under
multiple data recipient identifiers. multiple data recipient identifiers.
Objects provisioned under one "Protocol Client Identifier" Objects provisioned under one "Protocol Client Identifier"
MUST NOT be alterable by a provisioning session established MUST NOT be alterable by a provisioning session established
by another "Protocol Client Identifier". by another "Protocol Client Identifier".
FREQ12: The registry provisioning protocol MUST allow an SSP to
provision LUF-only or LUF+LRF data in the registry via a
single provisioning interface and data model.
3.2. Distribution of data into local data repositories 3.2. Distribution of data into local data repositories
This section targets use cases concerned with the distribution of SED This section targets use cases concerned with the distribution of SED
to local data repositories. This is considered out-of-scope for this to local data repositories. This is considered out-of-scope for this
version of the document. version of the document.
3.3. Miscellaneous Use Cases
This section contains additional use cases for consideration.
3.3.1. 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.3.2. TBD: 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.
4. Security Considerations 4. Security Considerations
Session establishment data allows for the routing of SIP sesions Session establishment data allows for the routing of SIP sesions
within, and between, SIP Service Providers. Access to this data can within, and between, SIP Service Providers. Access to this data can
compromise the routing of sessions and expose a SIP Service Provider compromise the routing of sessions and expose a SIP Service Provider
to attacks such as service hijacking and denial of service. The data to attacks such as service hijacking and denial of service. The data
can be compromised by vulnerable functional components and interfaces can be compromised by vulnerable functional components and interfaces
identified within the use cases. identified within the use cases.
5. IANA Considerations 5. IANA Considerations
This document does not register any values in IANA registries. This document does not register any values in IANA registries.
6. Acknowledgments 6. Acknowledgments
This document is a result of various discussions held by the DRINKS This document is a result of various discussions held by the DRINKS
requirements design team, which is comprised of the following requirements design team, which is comprised of the following
individuals, in alphabetical order: Deborah A Guyton (Telcordia), individuals, in alphabetical order: Deborah A Guyton (Telcordia),
Gregory Schumacher (Sprint), Jean-Francois Mule (CableLabs), Kenneth Gregory Schumacher (Sprint), Jean-Francois Mule (CableLabs), Kenneth
Cartwright (Verisign), Manjul Maharishi (Verisign), Penn Pfautz (AT&T Cartwright (TNS, Inc.), Manjul Maharishi (TNS, Inc.), Penn Pfautz
Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey, Nuestar; (AT&T Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey,
and Alexander Mayrhofer, enum.at GmbH), and the editors of this Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of
document. this document.
This specific version is primarily the result of feedback from David
Schwartz (Xconnect) and Jean-Francois Mule (CableLabs), with input
from other participants listed above.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References 7.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486, Interconnect (SPEERMINT) Terminology", RFC 5486,
March 2009. March 2009.
Author's Address Author's Address
Sumanth Channabasappa Sumanth Channabasappa
CableLabs CableLabs
858 Coal Creek Circle 858 Coal Creek Circle
Louisville, CO 80027 Louisville, CO 80027
 End of changes. 41 change blocks. 
246 lines changed or deleted 276 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/