IETF Draft:Concepts and Terminology for Peer to Peer SIP

摘要

本文是IETF Draft《Concepts and Terminology for Peer to Peer SIP》的中文翻译，本人的翻译处子作。由于个人技术和英语水平很有限，翻译时间较紧张，翻译得很是一般，但为了鼓励自己写技术blog，自己还是决意共享之。望轻拍，望多指正。

正文

这是上学 期《高级计算机网络技术》课程上做的翻译作业；亦是个人翻译的第一篇外文。

当时紧急，我只用了一天时间翻译，后来也没进行过修订。（暗语：应该N多语言上的毛病）

为了发扬互联网精神，我做出一个非常艰难的决定——羞羞共享之。

有什么重大问题，望指正。

注：直接从TXT上贴过来，只简单排了一下版，凑合看吧。。

原文地址： https://datatracker.ietf.org/doc/draft-ietf-p2psip-concepts/

Document type:	Active Internet-Draft (P2PSIP WG document)  Replaces draft-willis-p2psip-concepts
Last updated:	2010-10-25
State:	I-D Exists
Intended status:	-
Submission:	WG <p2psip>
Responsible AD:	-
Other versions:	plain text, pdf, html

Email Authors |  IPR Disclosures |  Dependencies to this draft |  Check nits |  Search Mailing Lists

译文

P2PSIP工作组                                                    D. Bryan

Internet-Draft                                         Cogent Force, LLC

拟状态：信息类                                       P. Matthews

到期日：2011年4月28日                       阿尔卡特朗讯(Alcatel-Lucent)

                                                                E. Shim

                                                             Avaya, Inc.

                                                               D. Willis

                                                       Softarmor Systems

                                                              S. Dawkins

                                                            华为（美国）

                                                          2010年10月25日

           

  Peer to Peer SIP的概念和术语

                  draft-ietf-p2psip-concepts-03

 

摘要

   本文档定义了在对等计算环境下会话初始化协议(SIP)使用相关的概念和术语；

   在此对等计算环境下，传统的代理注册器和消息路由功能已被一种分布式机制

   代替。这些机制可能通过使用一个分布式哈希表或者其他拥有相似外部属性

   的分布式数据机制得以实现。该文档包含一个在本文定义的描述网络元素之

   间功能关系的高层次视图、一个操作相关的概念模型，以及概念模型的操作，

   以及P2PSIP工作组和RELOAD协议（定义于[I-D.ietf-p2psip-base]和[I-D.ietf-p2psip-sip]）

   提及的相关问题的概述。这些相关问题由P2PSIP工作定义。

本备忘录的状态

   这次以互联网为草稿提交与在完全符合BCP 78和BCP 79的规定。

   互联网草案（Internet-Draft）是互联网工程任务组（Internet Engineering Task Force，IETF）

   的工作文档。注意，其他组织也可以分布自己的文档，以作为互联网草案。

   最新的互联网草案的列表记录于http://datatracker.ietf.org/drafts/current/。

 

   互联网草案的有效期最长为六个月，并可能会在任何时间被更新，替换，或被

   其他文件取代。将互联网草案用作引用材料或者引用它们当作“进行中的工作”

   以外的材料都是不适当的。

   这次互联网草案将于2011年4月28日到期。

版权声明

Bryan，等 2011年4月28日到期  [第1页]

互联网草案 P2PSIP概念和术语   2010年10月

   版权授予IETF信托和文档作者。保留所有权利。

   自本文档发布当天起，本文档服从于BCP 78和IETF信托的IETF文档相关法规

   （http://trustee.ietf.org/license-info）。请仔细阅读这些文档，因为

   它们描述了你对此文档的权利和限制。从此文档提取的代码组件必须包含4.e

   节描述的简化的BSD证书（Simplified BSD License）文本，同时正如简化的

   BSD证书所述，这些提供的代码组件是无担保的。

   本文档可能包含来自2008年11月10日之前发行或公开的IETF文档或IETF稿件的

   材料。部分拥有这些材料版权的人（们）可能没授予IETF信托修改这些在IETF

   标准化进程（IETF Standards Process）之外的材料的版权。除了将它格式化

   成为RFC进行发行或将它翻译成除了英语之外的其他语言，在没有获得这些材料

   的版权的情况下这些文档不能在IETF标准化进程之外进行修改，以及衍生出在

   IETF标准化进程之外没有产生的工作成果。

 

Bryan，等 2011年4月28日到期 [第2页]

互联网草案 P2PSIP概念和术语  2010年10月

 

目录

   1.  编者的话和这个版本的变化 . . . . . . . . . . . . . . . . . . .  4

   2.  背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  高层次描述 . . . . . . . . . . . . . . . . . . . . . . . . . .  5

     3.1.  服务 . . . . . . . . . . . . . . . . . . . . . . . . . . .  5

     3.2.  客户端 . . . . . . . . . . . . . . . . . . . . . . . . . .  6

     3.3.  P2PSIP和RELOAD的关系 . . . . . . . . . . . . . . . . . . .  6

     3.4.  P2PSIP和SIP的关系  . . . . . . . . . . . . . . . . . . . .  6

     3.5.  P2PSIP和其他地址记录（AoR）提取方法的关系. . . . . . . . .  7

     3.6.  NAT问题. . . . . . . . . . . . . . . . . . . . . . . . . .  7

   4.  参考模型 . . . . . . . . . . . . . . . . . . . . . . . . . . .  7

   5.  定义 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9

   6.  讨论 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

     6.1.  分布式数据库功能 . . . . . . . . . . . . . . . . . . . . . 13

     6.2.  分布式数据库功能的使用 . . . . . . . . . . . . . . . . . . 14

     6.3.  NAT 穿越 . . . . . . . . . . . . . . . . . . . . . . . . . 15

     6.4.  定位和加入一个叠加 . . . . . . . . . . . . . . . . . . . . 15

     6.5.  客户端和未修改的SIP设备的连接. . . . . . . . . . . . . . . 16

     6.6.  架构 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

   7.  未决问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

   8.  参考信息 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

   作者的联系方式 . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Bryan，等 2011年4月28日到期 [第3页]

互联网草案 P2PSIP概念和术语  2010年10月

   

1. 编者的话和这个版本的变化

   这个版本的草案较先前版本有较大的改动。从02版起，这项工作开始跟踪记录开

   放性问题，用于帮助各方在草案上达成共识。随着RELOAD的重选成这个工作组的

   协议，工作组的重心转移于完成RELOAD协议的草案，同时工作组指示编辑去更新

   此文档，以反映RELOAD协议完成完做出的决定。

   关于主要的开放性问题，请参阅第7节。

2. 背景

   

   互联网结点之间多媒体通信的一个基本问题是发现一个给定用户能到达的主机。

   在会话初始化协议（Session Initiation Protocol，SIP[RFC3261]）中，这个

   问题被表示为将用户的地址记录（Address of Record，AoR）映射到1个或多个

   可达URI（Contact URIs）的问题。AoR是一个用户名，其中用户独立于用户可

   达的可达的主机或主机群，而一个可达URI标识一个用户可达的主机。

   在常见的我们称之为“传统SIP”或“客户端/服务器端SIP”的SIP应用架构中，有一

   个比较固定的SIP路由代理和SIP用户代理的层次体系。为了传送一个SIP邀请信息（SIP INVITE）

   到一个用户可达的主机或主机群，一个SIP用户代理（UA）要遵循RFC3263中所指

   定的过程，进而确定一个SIP代理的IP地址，然后发送请求邀请信息（INVITE）到

   此SIP代理。接着，代理将收到的SIP邀请（SIP INVITE）传送到用户可达的主机。

   这份文件给出了对此问题的另一种解决方案的高层次描述。在这另一个解决方案里，

   相对固定的客户端/服务器端SIP的层次被对等叠加网络(Peer to Peer overlay network)

   所替代。在对等叠加网络，不同的AoR到可达URI的映射并不集中于代理/注册结点，

   而是分布于在个叠加网络的对等结点中。

   这一替代解决方案的细节由RELOAD协议所确定。RELOAD基础草案[I-D.ietf-p2psip-base]

   定义了一个使用分布式哈希表（Distributed Hash Table, DHT）的分配机制以及

   具体说明了线协议（wire protocol），安全性和需要传送信息的身份验证机制。

   此DHT协议是为了实现分布式SIP注册而专门设计的协议。在设计此协议的同时，其他

   应用亦会被

Bryan，等 2011年4月28日到期 [第4页]

互联网草案 P2PSIP概念和术语  2010年10月

   考虑，如果可能做出的设计决定使RELOAD协议应用于DHT适用的其他实例但不会

   因此给RELOAD协议增加不必要的复杂度。RELOAD协议草案[I-D.ietf-p2psip-sip]

   详细说明了RELOAD协议如何应用于SIP协议以实现一个分布式的、无服务器（server-less）

   的SIP解决方案。

3. 高层次描述

   一个P2PSIP叠加是一个以对等形式组织的节点的集合，这个叠加应用会话初始化

   协议（SIP）以实现实时(real-time)通信。在一个叠加里的那些节点共同地提供

   一种实现命名到叠加位置的映射的分布式机制。这即是提供了地址记录（Addresses of Record,AoR）

   到可达URI（Contact URIs）的映射，因此提供了RFC3261提及的“定位服务器”（location server）

   的功能。一个叠加还提供了一种消息传送功能，即在此叠加的任意两个结点之间

   可以相互传达SIP消息。

   一个P2PSIP叠加包括一个或多个称为对等端（Peer）的节点。在这个叠加里的所

   有对等端共同运行一个分布式数据库算法。这个分布式数据库算法允许数据存储

   在对等端中和并能够有效地被检索。它也可能确保一个数据项的副本存储在不止

   一个对等端中，因此一个对等端的失效不会导致叠加中数据项的丢失。

   此分布式数据库的一个应用是存储提供以AoR到可达URI的映射实现分布式定位功能

   所需要的信息。这提供了在每一个叠加里的定位功能，这与[RFC3263]描述的定位功

   能不一样。然而，[RFC3263]的模型用于不同叠加之间的定位。

3.1. 服务

   自然界的对等计算，是每一个对等端向其他对等端提供服务，从而使这个叠加的对等

   端共同提供更好的功能。在P2PSIP中，对等端提供存储和运输服务，使分布式数据库

   功能和分布式传送功能得到实现。此外，RELOAD协议提供了一个简单的针对TURN协议

   [RFC5766]的发现机制，其中TURN机制用于实现NAT的穿越。预计个别对等端还可以提

   供其他一些P2PSIP功能增强型的服务（例如支持语音信箱），或支持在超出SIP之外的

   其他应用。为了支持这些额外的服务，对等端可能需要存储在叠加的额外信息。

Bryan，等 2011年4月28日到期 [第5页]

互联网草案 P2PSIP概念和术语  2010年10月

   [I-D.ietf-p2psip-service-discovery]描述了基于P2PSIP的用于资源发现的机制。

3.2. 客户端

   一个叠加可能会也可能不会还包括一个或多个称为客户端的节点。RELOAD协议支持客

   户端作为没加入叠加的对等端，因此这些客户端并不路由消息或存储信息。客户端通

   过连接一个对等端访问RELOAD的服务，这个对等端执行代表客户端的操作。注意，在

   RELOAD协议中并没有显著的客户端协议。相反，一个使用相同协议的客户端连接，但

   从来没有以一个对等端的身份加入一个叠加。更多信息请参阅[I-D.ietf-p2psip-base]。

   请注意，在P2PSIP的上下文里有一个额外的实体，它有时候就被称为客户端。一个特殊

   的对等端可能是一个在P2PSIP叠加的成员，并可能呈现SIP注册、代理或重定向服务器

   到传统的SIP设备（SIP客户端）的一个或全部的功能。在这种方式下，现有的未修改的

   SIP客户端可以连接到网络。这些未修改的SIP设备不再使用RELOAD协议，这是一个与之

   前段落讨论的客户端概念截然不同的概念。

3.3. P2PSIP和RELOAD的关系

   P2PSIP工作组定义的RELOAD协议实现了一种主要用于用于无服务器，对等点对点的SIP部

   署的DHT。然而，RELOAD协议同样可用于其他应用程序。同样地，一个“P2PSIP”部署，一

   般认为是实现分布式SIP协议的一种RELOAD应用，但也有可能RELOAD只作为一种机制来分

   发其他应用程序，而与SIP完全无关。

3.4. P2PSIP和SIP之间的关系

   由于P2PSIP与实时通信的对等点对点网络有关，预计大部分对等端和客户端会联结于SIP实体

   配合工作（尽管RELOAD可以用于P2PSIP之外的其他应用）。例如，一个对等端可能会联结一

   个SIP UA，另一个可能联结一个SIP代理服务器，而第三个联结上一个SIP-to-PSTN网关。对于

   这样的结点，结点的对等端或客户端部分在逻辑在不同于SIP实体部分。然而，这有没有硬规

   定每个P2PSIP结点（对等端或客户端）可以连接到一个SIP实体。例如，额外的对等端可以被

   放置在叠加中以为RELOAD叠加提供额外的存储或冗余，但可能

Bryan，等 2011年4月28日到期 [第6页]

互联网草案 P2PSIP概念和术语  2010年10月

   没有直接的SIP功能。

3.5. P2PSIP和其他地址记录（AoR）提取方法的关系

   未决问题：之前做下的许多“决定”已经被移出主文档。然而，这文档似乎指

   出了一个差别。那这部分会不会被移动或被删除？

   如上所述，P2PSIP的基本任务是将AoR转换成可达路径。这个任务可能会使用零配置网络

   （zeroconf）技术进行实现，如组播DNS（multicast DNS,mDNS）和DNS服务发现（DNS 

   Service Discovery,DNS SD）技术（如苹果公司的Bonjour协议），本地链路多播名称解

   析技术[RFC4795]和动态DNS技术[RFC2136]。

   这些替代方案过去一直在P2PSIP工作组里被讨论，同时因为其扩展性、断开状态下的工作

   能力、分区恢复等等原因，这些方案并没被看好会成为一般的解决方案。然而，这似乎存

   在使用DNS-SD和的mDNS实现P2PSIP叠加的引导（bootstrapping）的进一步的兴趣。

3.6. NAT问题

   网络地址转换（NAT）是建立并维持对等点对点网络的障碍，因为NAT的直接阻碍对等端之间

   的通信。一些对等点对点网络架构通过坚持所有的对等端存在在同一个地址空间避免这个问

   题。然而，RELOAD提供了一些功能，使对等端位于多个地址空间通过NAT进行内联，允许RELOAD

   消息穿越NAT，并协助在NAT之间传输应用程序级的消息（例如SIP消息）。

4. 参考模型

   下图描述了一个P2PSIP叠加，其包括一系列的对等端，一个客户端和一个普通的SIP UA。这展

   示了一个典型P2PSIP叠加，但它不限制其他成分或变化；例如，代理对等端P可能同时也跟一个

   普通SIP代理服务器通话。这个特性不是要叠加所有可能的结构变化，而只是简单展示一种融合

   许多常见P2PSIP元素的部署。

Bryan，等 2011年4月28日到期 [第7页]

互联网草案 P2PSIP概念和术语  2010年10月

   图: P2PSIP叠加参考模型

   在这里，大外围描绘的“＃”表示对叠加的一种程序化视图（实际的连接可能是一个

   网格，一环，或其他一些结构）。围绕叠加周边的矩形，我们有一系列的对等端。

   每个结点都标有相对配的SIP实体——例如，“Proxy Peer P”指一个对等端P，它与一

   个SIP代理服务器相对配。在某些情况下，对等端或客户端可能会与两个或两个以上

   的SIP实体相对配。我们在此图有一个PSTN网关与同行的“G”，三个对等端（“D”，

   “E”，“F”）分别与一个UA相结合，对等端“P“结合

Bryan，等 2011年4月28日到期 [第8页]

互联网草案 P2PSIP概念和术语  2010年10月

   一个SIP代理服务器，一个没有的SIP功能的普通的对等端“Q”，以及一个对等端“R”，

   它这与一个SIP重定向服务器相对配。请注意，因为这些都是对等端，每个都要负责

   存储资源记录和传输环绕叠加的消息。

   到左边，两个对等端（“D”和“E”）在网络地址转换（NATs）后。这些对等端包含在P2PSIP

   叠加当中，从而参与存储资源记录和路由消息，尽管它们在NAT后。

   在右侧，我们有一个客户端“C”，它使用RELOAD协议与代理对等端“Q”进行通信。客户

   端“C”使用RELOAD从叠加里获取信息，但自身并没有加入叠加中，因此不参与路由信息

   或存储信息。

   在叠加下边，我们可见一个传统的SIP UA “A”，它并不是叠加的一部分，它要不是直接的

   一个对等端就是间接的一个客户端。它不使用RELOAD P2PSIP协议，也不以一个对等端或客

   户端的身份加入叠加中。另外地，它使用SIP协议与叠加互联，通过一个适配对等端或一个

   使用RELOAD与叠加进行通信的对等端。

   与SIP代理服务器对配的对等端”P“和与SIP重定向服务器对配的对等端“R”都可以以普通SIP

   设备和叠加之间的适配器角色进行服务。它们每个都接受标准SIP请求并通过使用P2PSIP协议

   获取叠加的路由信息解决下一跳（next-hop）问题，然后适当地处理SIP请求（对下一路进行

   代理或重定向）。注意，该代理操作是双向的——代理可能会转发从一个普通SIP设备到叠加或

   者从P2PSIP叠加到一个普通SIP设备的一个请求。

   在对等端“G”的PSTN网关提供了一个相类似的适配功能，以适应与公共交换电话网（PSTN）的

   交互。

5. 定义

   本节定义了一系列在理解P2PSIP工作上至关重要的概念。

   叠加网络：叠加网络是一个建立在另一个网络上层的计算机网络。在叠加上的节点可以

      认为是由虚拟或逻辑链路连接的，每个对应于在底层网络的一条路径，或者通过许多

 物理链路。例如，很多对等点到点网络是叠加网络，因为它们运行在

Bryan，等 2011年4月28日到期 [第9页]

互联网草案 P2PSIP概念和术语  2010年10月

      互联网上。拨号互联网就是一个在电话网络之上的叠加网络。 

 <http://en.wikipedia.org/wiki/P2P_overlay>

   P2P网络：一个对等点对点（Peer-to-Peer，P2P）计算机网络是一个主要依赖于

      网络所有参与者的计算能力和的带宽的网络，它不同于依赖于集中的相对少数

 量的服务器的传统网络。 P2P网络通常用于通过大量的ad-hoc连接进行结点互

 联。这种网络具有许多用途，共享包含音频，视频，数据或任何数字格式等内

 容文件（见<http://en.wikipedia.org/wiki/File_sharing>）是很常见的，

 同时实时数据，如电话话务量，也是使用P2P技术进行交换。<http://en.wikipedia.org/wiki/Peer-to-peer>.

 P2P网络也可以被称为“P2P叠加”或“P2P叠加网络“或”P2P网络叠加“，因为它不

 在物理层上组织，而是组织在现有的互联网协议网络的“顶层”。

   P2PSIP：一组和会话初始化协议（SIP）[RFC3261]相联系的通信协议的套件，它可

      以使SIP使用对等点对点技术去实现SIP请求的目标，提供SIP消息传输，并提供

 其他SIP相关的功能。目前，这些协议包括：[I-D.ietf-p2psip-base], 

 [I-D.ietf-p2psip-sip],[I-D.ietf-p2psip-diagnostics], 

 [I-D.ietf-p2psip-service-discovery] and [I-D.ietf-p2psip-self-tuning].

   用户：通过对等端和客户端上的SIP UA（或可能其他方式）与叠加交互的自然人。

      接着下面的术语只在P2PSIP范围内进行定义。这些定义项可能会和其他机构文献

 相冲突。本文档的某些早期版本在每个词前加了前缀“P2PSIP”，以说明这个词的

 范围。这个前缀已经从文本里去除;然而，这使用范围仍然适用。

   叠加名称：一个人性化的名称，用于标识一个特定的P2PSIP叠加。这存在于URI（其中

      一部分）的格式中，但在DNS可能没有相关记录。

   对等端：一个参与P2PSIP叠加的结点，它提供向其他在相同P2PSIP叠加的结点

      存储和运输服务。每个对等端在相应的叠加内有一个唯一的标识，以作为对等端标识

 （Peer-ID）。每个结点可能被耦合到一个或多个SIP实体。在特定一个叠加的范围内，

 对等端有能力执行几个不同的的操作，如加入和退出叠加、在叠加内传输SIP消息、

 存储标识叠加的信息、

Bryan，等 2011年4月28日到期 [第10页]

互联网草案 P2PSIP概念和术语  2010年10月

      向叠加内发布消息、从叠加中获取信息。

   对等端标识：唯一标识给定的叠加内一对等端的信息。此数值并不人性化——它通过

      DHT获取，是在哈希空间的一个数值。这些对等端ID是完全独立于与一个对

 等端联系的任何用户和用户代理的标识。（注：在P2P领域内它也通常称为

 “结点ID”（Node-ID））。

   客户端：一个参与P2PSIP叠加的结点，但它并不存储信息或转发消息。一个客户

      端也可以认为是一个尚未加入叠加的对等端。

   用户名：一个标识用户的人性化名称。该名称在叠加内必须是唯一的，也可

      以在更大范围内唯一。用户名要编码格式化，所以它们能组合到一个URI内

 （很可能是一个SIP URI），也许与叠加名进行组合。

   服务：由一个对等端贡献的针对一个叠加或叠加的成员的能力。不是所有的对等端

      和客户端提供相同的服务集合，而且P2PSIP提供定位服务的服务发现机制。

   服务名称：为标识服务的一个唯一的，人性化的名称。

   资源：任何存储在叠加内的信息。举例说明，用户和服务就是资源。

   资源标识：一个非人性化的数值，它唯一标识资源，被用作存储和检索相关资源数据

      的关键词。生成资源标识的一种方法是通过应用映射功能，将标识映射到其他一

 些唯一的描述资源的名称（比如用户名或服务名）。资源标识用在分布式数据库

 算法里，以确定负责为叠加存储数据的一个或多个对等端。

   资源记录：数据块，通过叠加的分布式数据库机制进行存储，它包括与一个指定资源

      相关的信息。我们推测，可能有多种类型的资源记录。有些资源记录可能是关于用

 户的数据，而其他资源记录可能关于服务的数据，同时工作组可能定义其他类型。

      种类，用途，以及记录格式是将来待研究的问题。

Bryan，等 2011年4月28日到期 [第11页]

互联网草案 P2PSIP概念和术语  2010年10月

   主责对等端：负责储存资源的资源记录的对等端。在此领域内，“根对等端”

      （Root Peer）也用于此概念。

   对等端协议：P2PSIP叠加对等端之间的用于共享信息和组织P2PSIP叠加网络的通

      话协议。在P2PSIP中，这协议通过RELOAD[I-D.ietf-p2psip-base]协议实现。

   客户端协议：客户端和对等端之间的通话协议。在P2PSIP和RELOAD中，客户端协议

      在语法上是相同的协议。唯一不同的是，客户端不进行路由消息或路由信息，

 也没把（或没能力把）自己本身插入叠加中。

   对等端协议连接/ P2PSIP客户端协议连接：

      基于TLS，DTLS，TCP，UDP或其他传输层协议传送RELOAD对等端协议消息的连接。

   邻居：能直接感知或不需进一步查找就可到达的P2PSIP对等端的集合。

   待加入的对等端（Joining Peer）：一个尝试成为特定一叠加的对等端的对等端的结点。

   引导对等端(Bootstrap Peer)：在叠加内的一个对等端，它是正参与的对等端的连接的

      第一个点。它选择对等，这将以接纳对待端的角色进行服务，帮助待加入的对等端

 联系接纳对等端。

   接纳对等端（Admitting Peer）：在重叠的一个对等端，它帮助待加入的对等端

      加入叠加。成为将接纳对等端的机率可能取决于待加入的对等端（如，取决于

 待加入的对等端的对待端标识）。例如，一对等端被选作接纳对等端可能因为

 它是在叠加架构里“最靠近”于未来待加入的对等端位置的对等端。接纳对等端

 的选择通常是由引导对等端完成的。对于引导对等端去选择自己成为接纳对等

 端，这是可允许的。

 

   启动服务器：用于定位引导对等端的网络节点。一个启动服务器，可以作为将加入

      的对等端和引导对等端之间消息的一个代理。此启动服务器本身是一个典型的

 稳定的主机，其DNS名称在某种程度被传达（例如，通过在网页的配置、规范

 或使用DHCP）到想加入叠加的对等端。一个启动服务器是不要求成为一个对等

 端或客户端，尽管它在需要的时候可以成为。

Bryan，等 2011年4月28日到期 [第12页]

互联网草案 P2PSIP概念和术语  2010年10月

   对待端接纳：接纳一个结点（“待加入的对等端”）成为对等端加入一个叠加的行为。

      接纳过后，此过程结束，待加入的对等端成为了叠加里一个功能完全的对等端。

      在接纳过程中，将加入的对等端可能需要出示凭据来证明它具有足够的权力来

 加入这个叠加。

   资源记录的插入：插入P2PSIP资源记录到分布式数据库的行为。随着插入，这些数据

      会被储存在一个或多个的对等端中。这些数据可以通过当作关键词的资源标识进行

 检索或更新。

6. 讨论

6.1. 分布式数据库功能

   一个P2PSIP叠加以一个分布式数据库运行。此数据库以一种存储资源相关信息的方法

   进行服务。信息的一块，即资源记录，可以通过一个采用资源标识这一关键词关联资

   源记录的数据库进行存储和检索。每个资源都必须有一个唯一的资源标识。除了唯一

   标识资源，资源标识也被用于分布式数据库算法，以确定在叠加中存储资源记录的一

   个或多个对等端。

   用户是可以使用叠加去进行购物和接听电话之类事情的人类。存储在关联一个用户的资

   源记录的信息可以包括用户的全名以及用户正使用的用户代理的位置（用户的SIP AoR）。

   使用RELOAD如何实现相关的所有细节都提供于[I-D.ietf-p2psip-sip]。

   在有关用户信息可以存储在叠加之前，一个用户需要一个用户名。用户名是一个人性化的

   标识符，在叠加内它唯一地标识一个用户。在RELOAD中，用户被签发证书，这如中央签署

   的证书，可标识用户名同时标识一个确切数量的资源标识，用户在其中存储了他们的信息。

   想了解更多信息，请参阅[I-D.ietf-p2psip-base]。

   该P2PSIP协议套件也标准化定位服务的相关信息。服务表现成一个对等端（或许还和一个客户

   端）能够使在叠加内其他对等端和客户获得便利的行为。可能存储在与服务相关联的资源记

   录的信息包括提供服务的对等端（或许还和一个客户端）。P2PSIP的服务发现

Bryan，等 2011年4月28日到期 [第13页]

互联网草案 P2PSIP概念和术语  2010年10月

   被定义在[I-D.ietf-p2psip-service-discovery]。

   每个服务都有一个人性化的服务名，它唯一标识服务。像用户名，服务名不是一个

   资源标识，而该资源标识是通过叠加采用的分布式数据库算法的一些功能由服务名

   派生的。

   一类称为分布式哈希表的算法<http://en.wikipedia.org/wiki/P2P_overlay>是一种

   实现分布式数据库的方式。RELOAD协议可扩展，并允许实现多个不同的DHT，但它具

   体指定一个在修改的Chord DHT的形式下实现DHT的强制方式。更多信息，请查阅[Chord]。

6.2. 分布式数据库的功能的使用

   虽然分布式数据库在之前的部分描述了许多通过SIP建立多媒体会话的方法，在RELOAD

   基本草案定义的基本机制和SIP使用归纳如下。这是一个非常简单的概述。如需详细信

   息，请参阅RELOAD基本草案。

   一个用户的联系信息存储在针对于此用户的资源记录里。假定用户正在使用一个设备，

   在此某对等端A，它作为一个联系点为此用户服务。用户添加联系信息到资源记录，此

   记录通过RELOAD证书机制进行授权。这资源记录本身连存储在网络的对等端Z，在此网

   络里Z是被叠加里采用的一个特定的分布式数据算法选择成为服务用户的对等端。

 

   当耦合对等端B的SIP实体收到一个发送给此用户的INVITE消息，它从对等端Z中检索出

   资源记录。然后它为不同的对等端提取联系信息，这些对等端是针对用户的联系点，其

   中包括对等端A，它们用叠加去建立与对等端A的一个连接。此连接包括任何适当的NAT

   穿越（细节并未显示）。

   请注意，RELOAD仅用于建立连接。一旦连接建立后，对等端之间的消息通过普通的SIP

   发送。

   这种交换如下图所示。记号"Store(U@A)"用来显示分布式数据库为用户U的联系A更新资

   源记录的操作，而记号“Fetch(U)”描述分布式数据库为用户U检索资源信息的操作。注意，

   对等端A、B和Z可能实际上经过内联的对等端（没显示）传送，

Bryan，等 2011年4月28日到期 [第14页]

互联网草案 P2PSIP概念和术语  2010年10月

   穿越NAT的干涉对等端结点（未显示），其作为分布式查找进程的一部分或之类的内容。

   

6.3. NAT穿越

   在P2PSIP使用RELOAD的NAT穿越，平等对待所有对等端，同时在他们之间建立一个

   非冗余网状连接。从一个对等端到另一个对等端的消息在网状连接的边缘进行路由

   直至它们到达目的地。为了使路由更有效率并避免使用标准的互联网路由协议，

   非冗余网状被组织成一种结构化的形式。如果该结构是基于任何一种常见的DHT算法，

   则任意两个对等端的最大跳数是log N，在此N是叠加中对等端的数目。存在的连接，

   应用了ICE NAT穿透技术[RFC5245]，用于建立对等端之间的新连接，同时也用于允许

   运行在对等端上的应用程序去建立与另一个对等端通信的连接。

6.4. 定位和加入一个叠加

   在一个对等端可以尝试加入一个P2PSIP叠加之前，它必须首先获得一个对等端标识、

   配置信息、和随意一系列证书。对等端标识是一个能够唯一标识叠加里的对等端的标识，

   同时证书表明此对等端被允许加入此叠加中。

 

   P2PSIP工作组不为如何获得对等端和证书强制性制定一个具体的机制，

Bryan，等 2011年4月28日到期 [第15页]

互联网草案 P2PSIP概念和术语  2010年10月

   但RELOAD基本草案里的确指明配置信息的格式，以及指定这些信息如何被获取，

   ，随着证书和对等端标识，从一个离线注册服务器。

   一旦获取配置信息，RELOAD基本草案指定一个机制，使一个对等端可能在一个配

   置文件中获取多播引导（nulticast-bootstrap）地址，而且可以广播此地址去

   尝试定位引导对等端。此外，对等端可能存储之前它见过的对等端并尝试把它们

   当作引导对等端，或者可能获取通过其他一些机制获取引导对等端的一个地址。

   更多详细信息，请参阅RELOAD基本草案（RELOAD base draft）。

   引导对等端的工作很简单：将待加入的对等端提交到一个对等端（即接纳对等端），

   此对等端会帮助待加入的对等端加入网络。 成为接纳对等端的机会取决于将加入

   的结点——例如，接纳对等端可能是待加入的对等端在叠加的一个邻居对等端。引导

   对等端可能也作为接纳对等端进行服务是可能的。

  

   接纳对等端将帮助待加入的对等端去了解其他在参加里的对等端并为他们建立适当

   的连接。接纳对等端和/或在叠加的其他对等端也将做任何需要去帮助待加入的对

   等端成为功能完全的对等端的事情。如何做到这一点的细节将取决于叠加使用的分

   布式数据库算法。

   在这个过程的不同阶段里，待加入的对等端可能被要求展示它的证书以表明它是被

   授权加入这个叠加。同样地，不同的可达的对等端可能被要求展示他们的证书所以

   待加入的对等端可以验证它是真的加入了它想加入的叠加里。

   

6.5. 客户端和未修改的SIP设备的连接

   如上所述，在RELOAD中，从此协议的角度看，客户端是简单地不用存储信息的，不用

   路由消息的，以及不用将它们本身加入叠加里的对等端。此相同的协议被用于实际的

   消息交换。注意，虽然此协议是相同的，但客户端不需要实现对等端的所有功能。例

   如，如果它从来路由消息，它将不需要扔有处理这类消息，或理解一个DHT的能力。

   对于SIP设备，另一种去实现此功能的方法是为对等端实现一个的[RFC3261]描述的代

   理/注册服务器。然后SIP设备使用

Bryan，等 2011年4月28日到期 [第16页]

互联网草案 P2PSIP概念和术语  2010年10月

   标准SIP机制去添加、更新和删除注册和发送SIP消息到对等端和其他客户端。作者在此

   提及这些设备仅仅是当作一种“SIP UA”，而不是“P2PSIP客户端”，以区别于上述描述的

   概念。

6.6. 架构

   通过RELOAD实现P2PSIP的架构如下文所示。一个应用程序，例如SIP（或其他使用RELOAD

   应用程序）使用RELOAD来定位其他对等端和（可选地）去建立这些对等端之间的连接，

   潜在地穿越NAT。消息可能还直接在对等端之间交换。此架构的整体块图如下图所示：

        __________________________

       |                                                   |

       |    SIP, 其他应用程序...                   |

       |             ___________________|

       |            |   RELOAD 层                   |

       |______|___________________|

       |         传输层                                  |

       |__________________________|

7. 未决问题

   未决问题：我们是否应该提供一个部分整理文档过去做出的决定，去保存历史的

   争议和防止过去的问题在将来再次被提出，或者简单地依赖于邮寄列表去解决这

   类担忧？

   未决问题：我们是否应该添加draft-bryan-p2psip-app-scenarios-00(已到期)

   的用例？在以前的版本里曾经对此有兴趣地，但是没有得出结论。

8. 参考信息

  [Chord]    Singh, K., Stoica, I., Morris, R., Karger, D., Kaashock,

              M., Dabek, F., and H. Balakrishman, "Chord: A scalable

              peer-to-peer lookup protocol for internet applications",

              IEEE/ACM Transactions on Neworking Volume 11 Issue 1, pp.

              17-32, Feb. 2003.

              可参考的副本：

              http://pdos.csail.mit.edu/chord/papers/paper-ton.pdf

Bryan，等 2011年4月28日到期 [第17页]

互联网草案 P2PSIP概念和术语  2010年10月

   [I-D.ietf-p2psip-base]

              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and

              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)

              Base Protocol", draft-ietf-p2psip-base-11 (work in

              progress), October 2010.

   [I-D.ietf-p2psip-diagnostics]

              Yongchao, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP

              Overlay Diagnostics", draft-ietf-p2psip-diagnostics-04

              (work in progress), July 2010.

   [I-D.ietf-p2psip-self-tuning]

              Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self-

              tuning Distributed Hash Table (DHT) for REsource LOcation

              And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-02

              (work in progress), July 2010.

   [I-D.ietf-p2psip-service-discovery]

              Maenpaa, J. and G. Camarillo, "Service Discovery Usage for

              REsource LOcation And Discovery (RELOAD)",

              draft-ietf-p2psip-service-discovery-01 (work in progress),

              July 2010.

   [I-D.ietf-p2psip-sip]

              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and

              H. Schulzrinne, "A SIP Usage for RELOAD",

              draft-ietf-p2psip-sip-05 (work in progress), July 2010.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,

              "Dynamic Updates in the Domain Name System (DNS UPDATE)",

              RFC 2136, April 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,

              A., Peterson, J., Sparks, R., Handley, M., and E.

              Schooler, "SIP: Session Initiation Protocol", RFC 3261,

              June 2002.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation

              Protocol (SIP): Locating SIP Servers", RFC 3263,

              June 2002.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform

              Resource Identifier (URI): Generic Syntax", STD 66,

              RFC 3986, January 2005.

   [RFC4795]  Aboba, B., Thaler, D., and L. Esibov, "Link-local

              Multicast Name Resolution (LLMNR)", RFC 4795,

              January 2007.

Bryan，等 2011年4月28日到期 [第18页]

互联网草案 P2PSIP概念和术语  2010年10月

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment

              (ICE): A Protocol for Network Address Translator (NAT)

              Traversal for Offer/Answer Protocols", RFC 5245,

              April 2010.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using

              Relays around NAT (TURN): Relay Extensions to Session

              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

作者的联系方式

   David A. Bryan

   Cogent Force, LLC

   Williamsburg, Virginia

   USA

   电话: +1 571 314 0256

   电子邮箱: [email protected]

   Philip Matthews

   Alcatel-Lucent

   600 March Road

   Ottawa, Ontario  K2K 2E6

   Canada

   电话: +1 613 784 3139

   电子邮箱: [email protected]

   Eunsoo Shim

   Avaya, Inc.

   233 Mt. Airy Road

   Basking Ridge, New Jersey  07920

   USA

   电子邮箱: [email protected]

Bryan，等 2011年4月28日到期 [第19页]

互联网草案 P2PSIP概念和术语  2010年10月

   Dean Willis

   Softarmor Systems

   3100 Independence Pkwy #311-164

   Plano, Texas  75075

   USA

   电话：+1 214 504 1987

   电子邮件：dean.willis @ softarmor.com

   Spencer Dawkins

   Huawei Technologies (USA)

   电话：+1 214 755 3870

   电子邮箱：[email protected]

Bryan，等 2011年4月28日到期 [第20页]