Internet Engineering Task Force (IETF) S. Channabasappa, Ed.
Request for Comments: 6461 CableLabs
Category: Informational January 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Channabasappa, Ed.
Request for Comments: 6461 CableLabs
Category: Informational January 2012
ISSN: 2070-1721
Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements
网络间/网络内SIP（饮料）用例和协议要求的可达性数据
Abstract
摘要
This document captures the use cases and associated requirements for interfaces that provision session establishment data into Session Initiation Protocol (SIP) Service Provider components to assist with session routing. Specifically, this document focuses on the provisioning of one such element termed the "registry".
本文档捕获了将会话建立数据提供给会话发起协议（SIP）服务提供商组件以协助会话路由的接口的用例和相关需求。具体而言，本文件重点介绍了一种称为“注册表”的元素的设置。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6461.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6461.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Overview ........................................................2
2. Terminology .....................................................5
3. Registry Use Cases ..............................................6
3.1. Category: Provisioning Mechanisms ..........................6
3.2. Category: Interconnect Schemes .............................7
3.3. Category: SED Exchange and Discovery Models ................8
3.4. Category: SED Record Content ...............................9
3.5. Category: Separation and Facilitation of Data Management ...9
3.6. Category: Public Identifiers, TN Ranges, and RNs ..........10
3.7. Category: Misc ............................................11
4. Requirements ...................................................11
4.1. Provisioning Mechanisms ...................................12
4.2. Interconnect Schemes ......................................12
4.3. SED Exchange and Discovery Requirements ...................12
4.4. SED Record Content Requirements ...........................12
4.5. Data Management Requirements ..............................13
4.6. Public Identifier, TN Range, and RN Requirements ..........13
4.7. Misc. Requirements ........................................13
5. Security Considerations ........................................14
6. Acknowledgments ................................................14
7. References .....................................................15
7.1. Normative References ......................................15
7.2. Informative References ....................................15
1. Overview ........................................................2
2. Terminology .....................................................5
3. Registry Use Cases ..............................................6
3.1. Category: Provisioning Mechanisms ..........................6
3.2. Category: Interconnect Schemes .............................7
3.3. Category: SED Exchange and Discovery Models ................8
3.4. Category: SED Record Content ...............................9
3.5. Category: Separation and Facilitation of Data Management ...9
3.6. Category: Public Identifiers, TN Ranges, and RNs ..........10
3.7. Category: Misc ............................................11
4. Requirements ...................................................11
4.1. Provisioning Mechanisms ...................................12
4.2. Interconnect Schemes ......................................12
4.3. SED Exchange and Discovery Requirements ...................12
4.4. SED Record Content Requirements ...........................12
4.5. Data Management Requirements ..............................13
4.6. Public Identifier, TN Range, and RN Requirements ..........13
4.7. Misc. Requirements ........................................13
5. Security Considerations ........................................14
6. Acknowledgments ................................................14
7. References .....................................................15
7.1. Normative References ......................................15
7.2. Informative References ....................................15
[RFC5486] (Section 3.3) defines 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 signaling path border elements (SBEs) need to establish a session. However, [RFC5486] does not specify the protocol(s) or format(s) to provision SED. To pave the way to specify such a protocol, this document presents the use cases and associated requirements that have been proposed to provision SED.
[RFC5486]（第3.3节）将会话建立数据或SED定义为用于将呼叫路由到与被叫域入口点关联的下一跳的数据。更具体地说，SED是传出信令路径边界元素（sbe）建立会话所需的一组参数。但是，[RFC5486]未指定提供SED的协议或格式。为了为指定这样一个协议铺平道路，本文件介绍了提议提供SED的用例和相关需求。
SED is typically created by the terminating or next-hop SIP service provider (SSP) and consumed by the originating SSP. To avoid a multitude of bilateral exchanges, SED is often shared via intermediary systems -- termed "registries" within this document. Such registries receive data via provisioning transactions from SSPs, and then distribute the received data into Local Data Repositories (LDRs). These LDRs are used for call routing by outgoing SBEs. This is depicted in Figure 1.
SED通常由终止或下一跳SIP服务提供商（SSP）创建，并由发起SSP使用。为了避免大量的双边交流，SED通常通过中介系统共享——在本文件中称为“注册中心”。此类注册中心通过SSP的供应事务接收数据，然后将接收到的数据分发到本地数据存储库（LDR）。这些LDR用于传出SBE的呼叫路由。这如图1所示。
*-------------*
1. Provision SED | |
-----------------------> | Registry |
| |
*-------------*
/ \
/ \
/ \
/ \
/ \
/ \
/ 2.Distribute \
/ SED \
V V
+----------+ +----------+
|Local Data| |Local Data|
|Repository| |Repository|
+----------+ +----------+
*-------------*
1. Provision SED | |
-----------------------> | Registry |
| |
*-------------*
/ \
/ \
/ \
/ \
/ \
/ \
/ 2.Distribute \
/ SED \
V V
+----------+ +----------+
|Local Data| |Local Data|
|Repository| |Repository|
+----------+ +----------+
Figure 1: General Diagram
图1：总图
In this document, we address the use cases and requirements for provisioning registries. Data distribution to local data repositories is out of scope for this document. The resulting provisioning protocol can be used to provision data into a registry or between multiple registries operating in parallel. In Figure 2, the case of multiple registries is depicted with dotted lines.
在本文档中，我们将介绍设置注册表的用例和需求。向本地数据存储库分发数据超出了本文档的范围。生成的配置协议可用于将数据配置到注册表中或在并行运行的多个注册表之间。在图2中，多个注册中心的情况用虚线表示。
. . . . . . .
. . . . . . . registry . . . . . . .
. . . . . . . . .
. . .
. . .
. . provision .
+-----------+ . +-----------+
| | provision +----------+ provision | |
| SSP 1 |------------>| Registry |<-----------| SSP 2 |
| | +----------+ | |
| +-----+ | /\ | +-----+ |
| | LDR | <-------------------- ------------------>| LDR | |
| +-----+ | distribute distribute | +-----+ |
| | | |
+-----------+ +-----------+
. .
. . . . . . . . . . . . . . . . . . . . . . . .
(provision / distribute)
. . . . . . .
. . . . . . . registry . . . . . . .
. . . . . . . . .
. . .
. . .
. . provision .
+-----------+ . +-----------+
| | provision +----------+ provision | |
| SSP 1 |------------>| Registry |<-----------| SSP 2 |
| | +----------+ | |
| +-----+ | /\ | +-----+ |
| | LDR | <-------------------- ------------------>| LDR | |
| +-----+ | distribute distribute | +-----+ |
| | | |
+-----------+ +-----------+
. .
. . . . . . . . . . . . . . . . . . . . . . . .
(provision / distribute)
Figure 2: Functional Overview
图2：功能概述
In addition, this document proposes two aggregation groups, as follows:
此外，本文件还提出了两个聚合组，如下所示：
o Aggregation of public Identifiers into a destination group.
o 将公共标识符聚合到目标组中。
o Aggregation of SED records into a route group.
o 将SED记录聚合到路由组中。
The use cases in Section 3.5 provide the rationale. The data model depicted in Figure 3 shows the various entities, aggregations, and the relationships between them.
第3.5节中的用例提供了基本原理。图3所示的数据模型显示了各种实体、聚合以及它们之间的关系。
+---------+ +--------------+ +---------+
| Data |0..n 0..n| Route | 1 0..n| SED |
|Recipient|------------| Group | --------------| Record |
+---------+ +--------------+ +---------+
|0..n |0..n
| |
| |
| |
|0..n |
1 +--------------+ 0..1 |
---------| Destination |--------- |
| | Group | | |
| +--------------+ | |
| | | |
| 1| | |
| | | |
| | | |
0..n | 0..n | | 0..n |
+---------+ +---------+ +----------+ |
| RN | | TN | | Public |----
| | | Range | |Identifier| 1
+---------+ +---------+ +----------+
+---------+ +--------------+ +---------+
| Data |0..n 0..n| Route | 1 0..n| SED |
|Recipient|------------| Group | --------------| Record |
+---------+ +--------------+ +---------+
|0..n |0..n
| |
| |
| |
|0..n |
1 +--------------+ 0..1 |
---------| Destination |--------- |
| | Group | | |
| +--------------+ | |
| | | |
| 1| | |
| | | |
| | | |
0..n | 0..n | | 0..n |
+---------+ +---------+ +----------+ |
| RN | | TN | | Public |----
| | | Range | |Identifier| 1
+---------+ +---------+ +----------+
Figure 3: Data Model Diagram
图3：数据模型图
The relationships are as described below:
这些关系如下所述：
- A public identifier object can be directly related to zero or more SED Record objects, and a SED Record object can be related to exactly one public identifier object.
- 公共标识符对象可以直接与零个或多个SED记录对象相关，而SED记录对象可以仅与一个公共标识符对象相关。
- A destination group object can contain zero or more TN (telephone number) Range objects, and a TN Range object can be contained in exactly one destination group object.
- 目的地组对象可以包含零个或多个TN（电话号码）范围对象，而TN范围对象只能包含在一个目的地组对象中。
- 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.
- 目标组对象可以包含零个或多个公共标识符对象，而公共标识符对象只能包含在一个目标组对象中。
- A destination group object can contain zero or more RN (routing number) objects, and an RN object can be contained in exactly one destination group object.
- 一个目标组对象可以包含零个或多个RN（路由号码）对象，而一个RN对象只能包含在一个目标组对象中。
- A route group object can contain zero or more SED Record objects, and a SED Record object can be contained in exactly one route group object.
- 路由组对象可以包含零个或多个SED记录对象，而SED记录对象只能包含在一个路由组对象中。
- A route group object can be associated with zero or more destination group objects, and a destination group object can be associated with zero or more route group objects.
- 路由组对象可以与零个或多个目标组对象关联，而目标组对象可以与零个或多个路由组对象关联。
- A data recipient object can be associated with zero or more route group objects, and a route group object can refer to zero or more data recipient objects.
- 数据接收方对象可以与零个或多个路由组对象关联，路由组对象可以引用零个或多个数据接收方对象。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document reuses terms from [RFC3261] (e.g., SIP), [RFC5486] (e.g., SSP, LUF, LRF, SED) and [RFC5067] (carrier-of-record and transit provider). In addition, this document specifies the following additional terms.
本文件重复使用了[RFC3261]（如SIP）、[RFC5486]（如SSP、LUF、LRF、SED）和[RFC5067]（记录和传输提供商的载体）中的术语。此外，本文件规定了以下附加条款。
Registry: The authoritative source for provisioned session establishment data (SED) and related information. A registry can be part of an SSP or be an independent entity.
注册表：提供的会话建立数据（SED）和相关信息的权威来源。注册表可以是SSP的一部分，也可以是独立实体。
Registrar: An entity that provisions and manages data into the registry. An SSP can act as its own registrar or -- additionally or alternatively -- delegate this function to a third party (who acts as its registrar).
登记员：向登记处提供和管理数据的实体。SSP可以作为其自己的注册机构，或者（另外或可选地）将此功能委托给第三方（作为其注册机构）。
Local Data Repository (LDR): The data store component of an addressing server that provides resolution responses.
本地数据存储库（LDR）：提供解析响应的寻址服务器的数据存储组件。
Public Identifier: A public identifier refers to a telephone number (TN), a SIP address, or other identity as deemed appropriate, such as a globally routable URI of a user address (e.g., sip:john.doe@example.net).
公共标识符：公共标识符是指电话号码（TN）、SIP地址或其他认为合适的标识，例如用户地址（例如SIP:john）的全局可路由URI。doe@example.net).
Telephone Number (TN) Range: A numerically contiguous set of telephone numbers.
电话号码（TN）范围：一组数字连续的电话号码。
Telephone Number (TN) Prefix: A preceding portion of the digits common across a series of E.164 numbers. A given TN prefix will include all the valid E.164 numbers that satisfy the expansion rules mandated by the country or the region with which the TNs comply.
电话号码（TN）前缀：一系列E.164号码中通用数字的前一部分。给定的TN前缀将包括所有有效的E.164号码，这些号码符合TNs所遵守的国家或地区规定的扩展规则。
Routing Number (RN): A Routing Number. For more information, see [RFC4694].
路由编号（RN）：路由编号。有关更多信息，请参阅[RFC4694]。
Destination Group: An aggregation of a set of public identifiers, TN Ranges, or RNs that share common SED, which is exposed to a common set of peers.
目的地组：共享公共SED的一组公共标识符、TN范围或RN的集合，该集合公开给一组公共对等方。
Data Recipient: An entity with visibility into a specific set of public identifiers (or TN Ranges or RNs), the destination groups that contain these public identifiers (or TN Ranges and RNs), and a route group's SED records.
数据接收者：对一组特定的公共标识符（或TN范围或RNs）、包含这些公共标识符（或TN范围和RNs）的目的地组以及路由组的SED记录具有可见性的实体。
Route Group: An aggregation that contains a related set of SED records and is associated with a set of destination groups. Route groups facilitate the management of SED records for one or more data recipients.
路由组：包含一组相关SED记录并与一组目标组关联的聚合。路由组便于管理一个或多个数据接收方的SED记录。
This section documents use cases related to the provisioning of the registry. Any request to provision, modify, or delete data is subject to several security considerations (see Section 5). The protocols that implement these use cases (and associated requirements) will need to explicitly identify and address them.
本节记录了与注册表设置相关的用例。任何提供、修改或删除数据的请求都要考虑几个安全因素（参见第5节）。实现这些用例（和相关需求）的协议需要明确地识别和解决它们。
UC PROV #1 Real-Time Provisioning: Registrars have operational systems that provision public identifiers (or TN Ranges or RNs) in association with their SED. These systems often function in a manner that expects or requires that these provisioning activities be completed immediately, as opposed to an out-of-band or batch provisioning scheme that can occur at a later time. This type of provisioning is referred to as "real-time" or "on-demand" provisioning.
UC PROV#1实时供应：登记员拥有提供与其SED相关的公共标识符（或TN范围或RNs）的操作系统。这些系统通常以期望或要求立即完成这些资源调配活动的方式运行，而不是以后可能出现的带外或批处理资源调配方案。这种类型的资源调配称为“实时”或“按需”资源调配。
UC PROV #2 Non-Real-Time Bulk Provisioning: Operational systems that provision public identifiers (or TN Ranges or RNs) and associated SED sometimes expect that these provisioning activities be batched up into large sets. These batched requests are then processed using a provisioning mechanism that is out of band and occurs at a later time.
UC PROV#2非实时批量供应：提供公共标识符（或TN范围或RNs）和相关SED的操作系统有时希望将这些供应活动分批放入大型集合中。然后，这些批处理请求使用带外并在稍后发生的供应机制进行处理。
UC PROV #3 Multi-Request Provisioning: Regardless of whether or not a provisioning action is performed in real time, SSPs often perform several provisioning actions on several objects in a single request or transaction. This is done for performance and scalability reasons, and for transactional reasons, such that the set of provisioning actions either fail or succeed atomically, as a complete set.
UC PROV#3多请求资源调配：无论是否实时执行资源调配操作，SSP通常在单个请求或事务中对多个对象执行多个资源调配操作。这样做是出于性能和可伸缩性原因，以及事务性原因，例如，作为一个完整的集合，供应操作集在原子上要么失败，要么成功。
UC INTERCONNECT #1 Inter-SSP SED: SSPs create peering relationships with other SSPs in order to establish interconnects. Establishing these interconnects involves, among other things, communicating and enabling the points of ingress and other SED used to establish sessions.
UC互连#1内部SSP SED：SSP与其他SSP创建对等关系，以建立互连。建立这些互连包括通信和启用入口点以及用于建立会话的其他SED。
UC INTERCONNECT #2 Direct and Indirect Peering: Some inter-SSP peering relationships are created to enable the establishment of sessions to the public identifiers for which an SSP is the carrier-of-record. This is referred to as "direct peering". Other inter-SSP peering relationships are created to enable the establishment of sessions to public identifiers for which an SSP is a transit provider. This is referred to as "indirect peering". Some SSPs take into consideration an SSP's role as a transit or carrier-of-record provider when selecting a route to a public identifier.
UC互连#2直接和间接对等：创建一些SSP间对等关系，以便能够建立到公共标识符（SSP是记录载体）的会话。这被称为“直接对等”。创建其他SSP间对等关系，以便能够建立与SSP作为传输提供商的公共标识符的会话。这被称为“间接对等”。一些SSP在选择到公共标识符的路线时，考虑到SSP作为记录提供者的中转站或承运人的角色。
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 differ from inter-SSP signaling points and SED.
UC INTERCONNECT#3内部SSP SED：SSP支持在其自身的公共标识符之间建立会话，而不仅仅是与其他SSP的公共标识符建立会话。除其他外，实现这一点涉及通信和启用SSP内信令点和其他SED，这些SED可能不同于SSP间信令点和SED。
UC INTERCONNECT #4 Selective Peering (a.k.a. per-peer policies): SSPs create peering relationships with other SSPs in order to establish interconnects. However, SSP peering relationships often result in different points of ingress or other SED for the same set of public identifiers. This is referred to as "selective peering" and is done on a route group basis.
UC互连#4选择性对等（又称每对等策略）：SSP与其他SSP创建对等关系，以建立互连。然而，SSP对等关系通常会导致同一组公共标识符的不同入口点或其他SED。这称为“选择性对等”，是在路由组的基础上进行的。
UC INTERCONNECT #5 Provisioning of a delegated hierarchy: An SSP may decide to maintain its own infrastructure to contain the route records that constitute the terminal step in the LUF. In such cases, the SSP will provision registries to direct queries for the SSP's public identifiers to its own infrastructure rather than provisioning the route records directly. For example, in the case of DNS-based route records, such a delegated hierarchy would make use of NS and CNAME records, while a flat structure would make use of NAPTR resource records.
UC互连#5委托层次结构的供应：SSP可决定维护其自身的基础设施，以包含构成LUF中终端步骤的路由记录。在这种情况下，SSP将提供注册表，以将SSP公共标识符的查询定向到其自身的基础设施，而不是直接提供路由记录。例如，在基于DNS的路由记录的情况下，这样的委托层次结构将使用NS和CNAME记录，而平面结构将使用NAPTR资源记录。
UC SED EXCHANGE #1 SED Exchange and Discovery using unified LUF/LRF: When establishing peering relationships, some SSPs may wish to communicate or receive SED (e.g., points of ingress) that constitutes the aggregated result of both LUF and LRF.
UC SED交换#1使用统一LUF/LRF的SED交换和发现：在建立对等关系时，一些SSP可能希望通信或接收构成LUF和LRF聚合结果的SED（例如入口点）。
UC SED EXCHANGE #2 SED Exchange and Discovery using LUF's Domain Name: When establishing peering relationships, some SSPs may not wish to communicate or receive points of ingress and other SED using a registry. They only wish to communicate or receive domain names (LUF step only), and then independently resolve those domain names via [RFC3263] to the final points of ingress data (and other SED).
UC SED交换#2使用LUF域名的SED交换和发现：在建立对等关系时，一些SSP可能不希望使用注册表通信或接收入口点和其他SED。他们只希望通信或接收域名（仅限LUF步骤），然后通过[RFC3263]将这些域名独立解析到最终的入口数据点（和其他SED）。
UC SED EXCHANGE #3 SED Exchange and Discovery using LUF's Administrative Domain Identifier: When establishing peering relationships, some SSPs may not wish to communicate or receive points of ingress and other SED using a registry. They only wish to communicate or receive an administrative domain identifier, which is not necessarily resolvable via DNS. The subsequent process of using that administrative domain
UC SED交换#3使用LUF管理域标识符的SED交换和发现：在建立对等关系时，一些SSP可能不希望使用注册表通信或接收入口点和其他SED。他们只希望通信或接收管理域标识符，这不一定可以通过DNS解析。使用该管理域的后续过程
identifier to select points of ingress or other SED can be SSP specific and is out of scope for this document.
用于选择入口点或其他SED的标识符可能是特定于SSP的，不在本文件范围内。
UC SED EXCHANGE #4 Coexistent SED Exchange and Discovery Models: When supporting multiple peering relationships, some SSPs have the need to concurrently support all three of the SED Exchange and Discovery Models already described in this section (Section 3.3) for the same set of public identifiers.
UC SED交换#4共存SED交换和发现模型：当支持多个对等关系时，一些SSP需要同时支持本节（第3.3节）中已描述的同一组公共标识符的所有三个SED交换和发现模型。
UC SED RECORD #1 SED Record Content: Establishing interconnects between SSPs involves, among other things, communicating points of ingress, the service types (SIP, SIPS, etc.) supported by each point of ingress, and the relative priority of each point of ingress for each service type.
UC SED记录#1 SED记录内容：在SSP之间建立互连包括通信入口点、每个入口点支持的服务类型（SIP、SIP等），以及每个服务类型的每个入口点的相对优先级。
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 identifier. In order to accomplish this, SSPs sometimes specify the TTL associated with a given SED record.
UC SED记录#2生存时间（TTL）：出于性能原因，查询SSP有时会缓存以前已查找过的给定公共标识符的SED。为了实现这一点，SSP有时会指定与给定SED记录关联的TTL。
UC DATA #1 Separation of Provisioning Responsibility: An SSP's operational practices often separate the responsibility of provisioning the points of ingress and other SED from the 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 subscriber, the SSP's provisioning systems provision the associated public identifiers.
UC数据#1供应责任分离：SSP的运营实践通常将供应入口点和其他SED的责任与供应公共标识符（或TN范围或RNs）的责任分离。例如，网络工程师可以与对等SSP的网络建立物理互连，并提供相关的域名、主机和IP寻址信息。单独地，对于每个新订户，SSP的供应系统提供相关的公共标识符。
UC DATA #2 Destination Groups: SSPs often provision identical SED for large numbers of public identifiers (or TN Ranges or RNs). For reasons of efficiency, groups of public identifiers that have the same SED can be aggregated. These aggregations are known as destination groups. The SED is then indirectly associated with destination groups rather than with each individual public identifier (or TN Ranges or RNs).
UC数据#2目的地组：SSP通常为大量公共标识符（或TN范围或RN）提供相同的SED。出于效率考虑，可以聚合具有相同SED的公共标识符组。这些聚合称为目标组。然后，SED间接与目的地组关联，而不是与每个单独的公共标识符（或TN范围或RNs）关联。
UC DATA #3 Route Groups: SSPs often provision identical SED for large numbers of public identifiers (or TN Ranges or RNs), and then expose that relationship between a group of SED records and a group of public identifiers (or TN Ranges or RNs) to one or more SSPs. This combined grouping of SED records and destination groups facilitates efficient management of relationships and the list of peers (data recipients) that can look up public identifiers and receive the associated SED. This dual set of SED records and destination groups is termed a "route group".
UC数据#3路由组：SSP通常为大量公共标识符（或TN范围或RN）提供相同的SED，然后将一组SED记录和一组公共标识符（或TN范围或RN）之间的关系公开给一个或多个SSP。SED记录和目标组的组合有助于高效管理关系和对等方（数据接收方）列表，这些对等方可以查找公共标识符并接收相关的SED。这两组SED记录和目的地组被称为“路由组”。
UC PI #1 Additions and Deletions: SSPs often allocate and de-allocate specific public identifiers to and from end-users. This involves, among other things, activating or deactivating specific public identifiers (TN Ranges or RNs), and directly or indirectly associating them with the appropriate points of ingress and other SED.
UC PI#1添加和删除：SSP通常向最终用户分配和取消分配特定的公共标识符。这包括，除其他事项外，激活或停用特定的公共标识符（TN范围或RNs），并直接或间接地将其与适当的入口点和其他SED关联。
UC PI #2 Carrier-of-Record versus Transit Provisioning: Some inter-SSP peering relationships are created to enable the establishment of sessions to the public identifiers (or TN Ranges or RNs) for which an SSP is the carrier-of-record. Other inter-SSP peering relationships are created to enable the establishment of sessions for which an SSP is a transit provider. Some SSPs take into consideration an SSP's role as a transit or carrier-of-record provider when selecting a route.
UC PI#2记录载体与传输资源调配：创建一些SSP间对等关系，以便能够建立到SSP作为记录载体的公共标识符（或TN范围或RNs）的会话。创建其他SSP间对等关系，以建立SSP作为传输提供商的会话。一些SSP在选择路线时考虑了SSP作为记录提供者的中转站或承运人的角色。
UC PI #3 Multiplicity: As described in previous use cases, SSPs provision public identifiers (or TN Ranges or RNs) and their associated SED for multiple peering SSPs, and as both the carrier-of-record and transit provider. As a result, a given public identifier (or TN Range or RN) key can reside in multiple destination groups at any given time.
UC PI#3多样性：如前一个用例所述，SSP为多个对等SSP提供公共标识符（或TN范围或RNs）及其相关SED，并同时作为记录载体和传输提供者。因此，给定的公共标识符（或TN范围或RN）密钥可以在任何给定时间驻留在多个目标组中。
UC PI #4 Destination Group Modification: SSPs often change the SED associated with a given public identifier (or TN Range or RN). This involves, among other things, directly or indirectly associating them with a different point of ingress, different services, or different SED.
UC PI#4目的地组修改：SSP经常更改与给定公共标识符（或TN范围或RN）关联的SED。这包括直接或间接地将它们与不同的入口点、不同的服务或不同的SED关联。
UC PI #5 Carrier-of-Record versus Transit Modification: SSPs may have the need to change their carrier-of-record versus transit role for public identifiers (or TN Ranges or RNs) that they previously provisioned.
UC PI#5记录载体与运输修改：SSP可能需要更改其先前提供的公共标识符（或TN范围或RN）的记录载体与运输载体角色。
UC PI #6 Modification of Authority: An SSP indicates that it is the carrier-of-record for an existing public identifier or TN Range. If the public identifier or TN Range were previously associated with a different carrier-of-record, then there are multiple possible outcomes, such as a) the previous carrier-of-record is disassociated, b) the previous carrier-of-record is relegated to transit status, or c) the new carrier-of-record is placed in inactive mode. The choice may be dependent on the deployment scenario and is out of scope for this document.
UC PI#6权限修改：SSP表示它是现有公共标识符或TN范围的记录载体。如果公共标识符或TN范围先前与不同的记录载体相关联，则存在多个可能的结果，例如a）先前的记录载体被解除关联，b）先前的记录载体被降级为传输状态，或c）新的记录载体被置于非活动模式。选择可能取决于部署场景，不在本文档的范围内。
UC MISC #1 Number Portability: The SSP wishes to provide, in query response to public identifiers, an associated routing number (RN). This is the case where a set of public identifiers is no longer associated with the original SSP but has been ported to a recipient SSP, who provides access to these identifiers via a switch on the Signaling System Number 7 network identified by the RN.
UC MISC#1号码可移植性：SSP希望在对公共标识符的查询响应中提供相关路由号码（RN）。在这种情况下，一组公共标识符不再与原始SSP关联，而是被移植到接收者SSP，接收者SSP通过RN标识的7号信令系统网络上的交换机提供对这些标识符的访问。
UC MISC #2 Data Recipient Offer and Accept: When a peering relationship is established (or invalidated), SSPs provision (or remove) data recipients in the registry. However, a peer may first need to accept its 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数据接收方提供和接受：当对等关系建立（或无效）时，SSPs提供（或删除）注册表中的数据接收方。但是，对等方可能首先需要接受其角色（作为数据接收方），然后才能使此类更改生效。或者，可以为给定的数据接收方配置自动接受功能。
UC MISC #3 Open Numbering Plans: In several countries, an open numbering plan is used, where the carrier-of-record is only aware of a portion of the E.164 number (i.e., the TN prefix). The carrier-of-record may not know the complete number or the number of digits in the number. The rest of the digits are handled offline (e.g., by a Private Branch Exchange, or PBX). For example, an SSP can be the carrier-of-record for "+123456789" and be the carrier-of-record for every possible expansion of that number, such as "+12345678901" and "+123456789012", even though the SSP does not know what those expansions could be. This can be described as the carrier-of-record effectively being authoritative for the TN prefix.
UC MISC#3开放编号计划：在一些国家，使用开放编号计划，其中记录载体只知道E.164编号的一部分（即TN前缀）。记录载体可能不知道完整编号或编号中的位数。其余数字脱机处理（例如，通过专用分支交换机或PBX）。例如，SSP可以是“+123456789”的记录载体，也可以是该数字的每个可能扩展的记录载体，例如“+12345678901”和“+123456789012”，即使SSP不知道这些扩展可能是什么。这可以被描述为有效地对TN前缀具有权威性的记录载体。
This section lists the requirements extracted from the use cases in Section 3. The objective is to make it easier for protocol designers to understand the underlying requirements and to reference and list
本节列出了从第3节中的用例中提取的需求。其目的是使协议设计者更容易理解底层需求，并参考和列出它们
the requirements that they support (or not). The requirements listed here, unless explicitly indicated otherwise, are expected to be supported. Protocol proposals are also expected to indicate their compliance with these requirements and highlight ones that they don't meet (if any). Furthermore, the requirements listed here are not meant to be limiting, i.e., protocol implementations and deployments may choose to support additional requirements based on use cases that are not listed in this document.
他们支持（或不支持）的需求。除非另有明确说明，否则此处列出的要求应得到支持。协议提案还应表明其符合这些要求，并强调其不符合的要求（如有）。此外，此处列出的需求并不意味着限制，即协议实现和部署可能会根据本文档中未列出的用例选择支持其他需求。
REQ-PROV-1: Real-time provisioning.
REQ-PROV-1：实时资源调配。
REQ-PROV-2: (Optional) Non-real-time bulk provisioning.
REQ-PROV-2：（可选）非实时批量供应。
REQ-PROV-3: Multi-request provisioning.
REQ-PROV-3：多请求供应。
REQ-INTERCONNECT-1: Inter-SSP peering.
REQ-INTERCONNECT-1：SSP间对等。
REQ-INTERCONNECT-2: Direct and Indirect peering.
REQ-INTERCONNECT-2：直接和间接对等。
REQ-INTERCONNECT-3: Intra-SSP SED.
REQ-INTERCONNECT-3：内部SSP SED。
REQ-INTERCONNECT-4: Selective peering.
REQ-INTERCONNECT-4：选择性对等。
REQ-INTERCONNECT-5: Provisioning of a delegated hierarchy.
REQ-INTERCONNECT-5：提供委托层次结构。
REQ-SED-1: SED containing unified LUF and LRF content.
REQ-SED-1：包含统一LUF和LRF内容的SED。
REQ-SED-2: SED containing LUF-only data using domain names.
REQ-SED-2:SED仅包含使用域名的LUF数据。
REQ-SED-3: SED containing LUF-only data using administrative domains.
REQ-SED-3：使用管理域仅包含LUF数据的SED。
REQ-SED-4: Support for all the other REQ-SED requirements (listed in this section), concurrently, for the same public identifier (or TN Range or RN).
REQ-SED-4：同时支持相同公共标识符（或TN范围或RN）的所有其他REQ-SED要求（本节列出）。
REQ-SED-RECORD-1: Ability to provision SED record content.
REQ-SED-RECORD-1：提供SED记录内容的能力。
REQ-SED-RECORD-2: (Optional) Communication of an associated TTL for a SED Record.
REQ-SED-RECORD-2：（可选）SED记录相关TTL的通信。
REQ-DATA-MGMT-1: Separation of responsibility for the provisioning the points of ingress and other SED, from the responsibility of provisioning public identifiers.
REQ-DATA-MGMT-1：将提供入口点和其他SED的责任与提供公共标识符的责任分开。
REQ-DATA-MGMT-2: Ability to aggregate a set of public identifiers as destination groups.
REQ-DATA-MGMT-2：能够将一组公共标识符聚合为目标组。
REQ-DATA-MGMT-3: Ability to create the aggregation termed route group.
REQ-DATA-MGMT-3：创建称为路由组的聚合的能力。
REQ-PI-TNR-RN-1: Provisioning of, and modifications to, the following aggregations: destination group and route groups.
REQ-PI-TNR-RN-1：提供和修改以下聚合：目的地组和路由组。
REQ-PI-TNR-RN-2: Ability to distinguish an SSP as either the carrier-of-record provider or the transit provider.
REQ-PI-TNR-RN-2：能够将SSP区分为记录提供商的载体或传输提供商。
REQ-PI-TNR-RN-3: A given public identifier (or TN Range or RN) can reside in multiple destination groups at the same time.
REQ-PI-TNR-RN-3：给定的公共标识符（或TN范围或RN）可以同时驻留在多个目标组中。
REQ-PI-TNR-RN-4: Modification of public identifier (or TN Range or RN) by allowing them to be moved to a different destination group via an atomic operation.
REQ-PI-TNR-RN-4：通过允许通过原子操作将公共标识符（或TN范围或RN）移动到不同的目标组来修改公共标识符。
REQ-PI-TNR-RN-5: SSPs can indicate a change to their role from carrier-of-record provider to transit, or vice versa.
REQ-PI-TNR-RN-5:SSP可以表示其角色从记录提供方的载体更改为传输，反之亦然。
REQ-PI-TNR-RN-6: Support for modification of authority with the conditions described in UC PI #6.
REQ-PI-TNR-RN-6：支持根据UC PI#6中描述的条件修改权限。
REQ-MISC-1: Number portability support.
REQ-MISC-1：号码可移植性支持。
REQ-MISC-2: Ability for the SSP to be offered a peering relationship and for the SSP to accept (explicitly or implicitly) or reject such an offer.
REQ-MISC-2：向SSP提供对等关系以及SSP接受（明示或暗示）或拒绝此类提议的能力。
REQ-MISC-3: Support for open numbering plans.
REQ-MISC-3：支持开放式编号计划。
Session establishment data allows for the routing of SIP sessions 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.
会话建立数据允许在SIP服务提供商内部和之间路由SIP会话。对这些数据的访问可能会破坏会话的路由，并使SIP服务提供商面临诸如服务劫持和拒绝服务等攻击。在用例中识别的易受攻击的功能组件和接口可能会破坏数据。
A provisioning framework or protocol that implements the described use cases MUST, therefore, provide data confidentiality and message integrity. Such frameworks and protocols MUST specify mechanisms to authenticate and authorize any entity that provisions data into the registry, i.e., that the entity is who it says it is and is allowed to use the provisioning interface. The determination of whether such an entity is authorized to provision specific data elements (e.g., a certain public identifier or TN Range) -- while REQUIRED -- may be left to local policy.
因此，实现所述用例的供应框架或协议必须提供数据机密性和消息完整性。此类框架和协议必须指定机制，以验证和授权向注册中心提供数据的任何实体，即该实体是它所说的实体，并且被允许使用提供接口。确定此类实体是否有权提供特定的数据元素（例如，某个公共标识符或TN范围）——尽管需要——可能由当地政策决定。
This document is a result of various contributions from (and discussions within) the IETF DRINKS Working Group; specifically, in alphabetical order: Alexander Mayrhofer, Deborah A Guyton, Gregory Schumacher, Jean-Francois Mule, Kenneth Cartwright, Manjul Maharishi, Penn Pfautz, Ray Bellis, Richard Shockey, and Syed Ali.
本文件是IETF饮料工作组的各种贡献（以及内部讨论）的结果；具体来说，按字母顺序排列：亚历山大·梅尔霍夫、黛博拉·盖顿、格雷戈里·舒马赫、让·弗朗索瓦·穆尔、肯尼斯·卡特赖特、曼珠尔·马哈里希、佩恩·普法茨、雷·贝利斯、理查德·肖基和赛义德·阿里。
The editor also wishes to thank the following for their comments and suggestions: Otmar Lendl, Sohel Khan, Peter Koch, Brian Rosen, Jon Peterson, Gonzalo Camarillo, and Stephen Farrell.
编辑还希望感谢以下人士的评论和建议：奥特玛·伦德尔、苏赫尔·汗、彼得·科赫、布赖恩·罗森、乔恩·彼得森、冈萨罗·卡马里洛和斯蒂芬·法雷尔。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486]Malas，D.和D.Meyer，“多媒体互连的会话对等（SPEERMINT）术语”，RFC 54862009年3月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[RFC4694] Yu, J., "Number Portability Parameters for the "tel" URI", RFC 4694, October 2006.
[RFC4694]Yu，J.，“电话”URI的号码可移植性参数”，RFC4694，2006年10月。
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, November 2007.
[RFC5067]Lind，S.和P.Pfautz，“基础设施枚举要求”，RFC 5067，2007年11月。
Author's Address
作者地址
Sumanth Channabasappa (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA
Sumanth Channabasapa（编辑）CableLabs 858美国科罗拉多州路易斯维尔市煤溪圈80027
EMail: sumanth@cablelabs.com
EMail: sumanth@cablelabs.com