网络工作组 O. Kassionen
互联网草案 T. Koskela
期望身份:报告 E. Harjula
到期:2010-01-11 M. Ylianttila
University of Oulu
2009-07-10
使用多重覆盖的点到点组管理机制
备忘录状态
这份草案完全符合BCP78和BCP79的规定而提交给IETF的。
互联网草案是IETF和它所涉及的领域和相关工作组的工作文档。注意其他团体也可以发布工作文档作为互联网草案。
互联网草案只是一个草案文档,它有六个月的最大有效时间,期间也可能被其他文档更新、替代或废弃。如果我们将它作为参考材料或者引用它,这是不合适的,它本身只能作为一个“工作进程”。
当前互联网草案清单可以通过以下链接获取:http://www.ietf.org/ietf/lid-abstracts.txt
互联网草案镜像目录列表可以在以下链接获取:
http://www.ietf.org/shadow.html
这个互联网草案将在2010年1月11日过期。
版权提示
Copyright (C)IETF Trust以及文档作者授权的人们。版权所有。
这篇文档符合BCP78以及IETF Trust文档合法条款,在文档正式出版发行有效(http://trustee.ietf.org/license-info)。请仔细浏览这些文档,因为它们描述了你在使用这篇文档的权利和限制。
摘要
这篇文档介绍了一种管理结构化P2P层次网络群组的机制。组管理加强了组成员之间高效而安全的交互行为,这得益于控制组级别的P2P消息传播和其它通信的范围。这篇文档介绍的组管理机制基于一种层次化方案。每个组有自己的地址空间、资源、消息路由信息而成为单独的层次化网络。一个很常见的覆盖网络用于分享组覆盖网(子覆盖网)的信息。
目录
1. 引言…………………………………………………………………………………
2. 专业术语……………………………………………………………………………
3. 框架概述……………………………………………………………………………
4. 操作概述……………………………………………………………………………
4.1.群组创建………………………………………………………………………..
4.2.群组维护………………………………………………………………………..
4.3.加入和离开群组………………………………………………………………..
4.4.群组移除………………………………………………………………………..
4.5.群组到ID别名的绑定…………………………………………………………
5. 数据格式……………………………………………………………………………
6. 性能考虑………………………………………………………………………….
7. 致谢……………………………………………………………………………….
8. IANA考虑………………………………………………………………………..
9. 安全考虑………………………………………………………………………….
10. 参考文献………………………………………………………………………….
10.1.规范参考…………………………………………………………………….
10.2. 报告参考…………………………………………………………………….
作者地址………………………………………………………………………………
1. 引言
社区网络服务的迅速流行,比如Facebook[FACEBOOK],Google Groups[GOOGLEGRP],Yahoo Groups[YAHOOGRP],更加凸显了组管理的重要性。特别是对于本身就是强调个人之间通信的P2P网络平台,就更加明显。群组间或群组中内容、信息分享可以看作是P2P网络背后主要的驱动力。用户加入一个网络通常是他有某种兴趣。所以他们也会很倾向去自己创建一些群组,我们管它叫社区。传统的P2P应用的使用者,这些应用比如资源分享,IP电话,视频/语音会议,正迅速以小组群的方式组织起来。
用户和服务形成群体性最主要原因是为了保护隐私而限制通信范围。群组内的成员在某种程度上都对各自持信任态度。群组也可以为了安全原因而使用,比如对群组的访问。这样组定义的资源和通信就只能在小组成员之间进行。尽管组管理被认为是P2P服务的基本功能,但是标准化倡议,例如IETF的P2PSIP工作组,并没有过多地关注它。
长期以来不同的P2P系统使用不同形式的组管理。最常见的方式是在应用层管理群组,例如,在P2P协议上使用一个单独的组管理协议。不过,如果用户想要在同一个组中使用多种应用,应用导向的组管理就不是最佳的方式。可能最出名的P2P层组管理机制就是在JXTA中使用的那种。在JXTA中,每个对等体是全球对等群组,叫做“NetPeerGroup”的一员,同时可以是一个或多个其它群组成员。但是JXTA并没有详细定义怎么创建和管理群组。在结构化P2P系统中,群组管理(例如应用层解决方案)最常见的一种方式就是每个群组使用单独的覆盖层。分层结构,比如[HIERAS]和[HierarchP2P],已经被建议作为提高结构化P2P网络路由效率的手段。不过,分层基础模型对于组管理目的也是有用的。
这篇文档描述了管理结构化P2P层次网络上的实体构成的群组机制。在被提议的组管理机制中,每个组形成一个针对这个组特定的P2P层次网络。组中成员参与路由事宜以及其他层次网上的事宜,这些是P2P协议和DHT算法定义了的。一个对等体可以是一个或多个组中的成员。
一个群组网络隔离了其他基于对等体活动的P2P网络之间特定组活动。这个层次性的访问手段有以下一些优势,相对于之前只使用一个大的覆盖网,网中包含了所有群组活动,可以使用独立的组管理机制。
--路由效率:小层次网提供一个更高效的路由,相对于单个层次网而言。在小层次网数更少。
--公平的负载分配:只有成员节点才有义务维持特定组。
--操作简单化:所有组关联的活动已经被包含中特定组的层次性网络中
--安全:安全的基础就是隔离了不同群组之间之间的通信。就没有必要再去单独监视群组资源的访问权限(当然所选择P2P协议安全手段如果适用除外)
--透明性:组管理系统支持DHT算法和基于DHT的P2P层次网协议的任意组合。还有,由于层次网间本身就是独立的,我们就可以再不同组层次网中采用不同的DHT算法。
所有对等体都是主层次网的成员。所介绍的机制使用主层次网来分发敢于现有群组和群组成员信息。每个对等体都可以访问关于群组公开的信息,因为对等体可以在主网中充当搜索功能。
在接下来几节,某些P2P协议相关的术语和操作实例将被使用。术语或细节还有动作可能会有些微差异,这取决于我们在实现群组管理机制时所采用的实际P2P协议。这篇文档试图使用对于绝大多数基于DHT的P2P协议很常见的术语和P2P操作。
解决方案尽最大可能利用现有P2P协议的数据存储(发布)和查找机制。
2. 专业术语
在这篇文档中使用的关键词“必须”,“不必”,“需要”,“应当”,“不该”,“推荐”,“可能”,“非强制的”的详细解释可参照RFC2119。
层次网络:在更低层网络上(实际中通常是IP网)的一种结构化P2P网络。
对等体:正如在P2PSIP术语中所说,它就是维持一个层次网络的节点。
客户:在P2PSIP术语中,它是指不参与维持层次网络,但使用对等体提供的服务的那些节点。
群组:在一个结构化P2P网络中的节点组成的任何组;它们之间的通信在一个群组中实现。
群组ID:人可读的或二进制标识,用以区分不同群组。在DHT系统中这个ID作为搜索相应群组信息的一个关键搜索字段。
群组描述:人可读的对一个群组的描述,特定一个群组ID的。
群组层次网:包含组中对等体的层次网。群组活动发生在群组层次网中。
主层次网:某个网络中所有对等体都是其成员的一个很大的层次网。用于发布群组层次网和组成员信息。
社区:群组的子类型;由人类用户组成的群组。人员的终端设备在群组层次网中充当对等体角色。
3. 框架概述
本文的组管理架构的核心理念就是在每个社区中使用一种DHT层次网,这样就产生了很多小的子层次网构成了主层次网的子集。这就形成了一个层次网的分级,每个DHT层次网都是自包含的,独立的网络,如图1所示。群组信息至少包含相关群组成员信息、组描述,这些都应当在主层次网中公布。如果用户希望私有群组,可以不用在主层次网中发布出来。在一个网络中可同时存在公开化的群组也可以有私有群组。
层次网之间管理正如图1呈现的那样,对等体1,2,3,4都是主层次网成员。对等体1,2是组A成员(因此在组层次网A里)。对等体2,4是组B成员。对等体不是任何群组成员。
4.操作概述
4.1.群组创建
一个新的群组被创建,以确立一个新的层次网(组层次网),在这个网里面发生各种群组活动。这种创建操作意味着一个新的P2P协议栈实例的创建,以便路由表,资源表登对于这个创建的组是特定的。在创建一个新组之前,创建者通过向主层次网发送一个资源查询请求,以便确定有没有同样ID的群组已经存在了。
在这个基本情形中,创建对等体将扮演组中的纽带节点。这意味着这个节点将响应其他想要加入群组节点的初始化请求。创建对等体不必是纽带节点;这个角色可以使用群组中任何其它节点来担当。
创建节点发布一个DHT键值对<组ID, 组信息>给主层次网。组信息包括纽带节点ID和它的联系信息,比如IP地址和端口号。还有,群组这时会发布一个成员列表,但此刻里面只有它自身。这个表有一个DHT键,它包含和一个与组ID对应“成员”短语;这样就可能其他对等体搜索组中的某个成员。最后,创建对等体发布一个键值对,其中键是个通配符以便匹配所有组,而值是群组ID。这里的“通配符”意味着任何对等体创建的群组使用同一个键;因此,搜寻键消耗很多资源,每个都与特定组关联。创建一个公开群组的动作序列如图2所示。
----------------------------------------------------------------------
| Main Overlay |
-----------------------------------------------------------------------
----|---- -----|--- ----|---- ----|----
|Peer 1| |Peer 2| |Peer 3| |Peer 4|
--------- --------- --------- --------
| | / |
---------------------------- /-----------------------------------
| Group Overlay A | | Group Overlay B |
案例情形:在不同层次网中的对等体
图1
如果一个节点不能承担层次网管理任务(如一个低能力的P2PSIP客户端),它却想建立一个群组,就需要询问其他节点(有更高能力和公开的IP地址)使之成为组创建者。这个有更高能力的节点将会暂时在主层次网中充当维护组信息的角色。一个节点可以是主层次网中的一个客户端,组层次网中的一个对等体,反之亦然。
群组可以是公开的也可以是私有的。私有群组不会向主层次网发布。同样的逻辑适用于全体成员。即使一个群组是公开的,成员关系可能是私有的,因此成员列表不会在这种情况下公开。
4.2.群组维护
群组维护涉及到主层次网中群组存在和群组关系信息的发布。还有,群组维护也包含层次维护信息(例如邻居节点之间的存活信号),在P2P协议中是这样要求的。发布重复地进行,如果一个层次网的P2P协议需要周期性更新资源对象的话。
在每个群组中,至少应该有一个对等体应当能维护群组层次网的路由和资源管理功能。如果所有的对等体都离开了组层次网以至于只有客户端存在,至少有个客户端应当成为对等体,或者有外部的一个对等体发出对等体服务请求(这个功能在这个版本的草案中尚未定义)。如果上述条件也不满足则这个群组将不复存在。
如果广播对等体离开了这个群组,而这个群组是公开的,另外某个对等体就应当充当这个角色;否则,主层次网中的公共群组信息的更新将会终止。
4.3.加入和离开群组
很典型的加入群组方法是通过纽带节点加入。这个节点最初是创建节点。加入可以通过组中任何一个对等体实现(如果协议支持的话),但通常加入节点知道相应的纽带节点,因为在主层次网中有广播这些信息。在公共群组的情形下,主层次网中是存在这些存活节点的信息的。而私有群组情形下,信息可以以某种方式转换,例如,通过e-mail或者一个纸质文档指引节点怎么联系上特定存在的层次网节点。怎样加入一个公共组的操作序列如图3所示。
Creator Peer Main Overlay
| |
| Lookup(group ID) |
|------------------------------------------------------>|
| Not found |
|<------------------------------------------------------|
| |
| New stack instance |
|------+ |
|<-----+ |
| |
| Publish(group ID, group info) |
|------------------------------------------------------>|
| OK |
|<------------------------------------------------------|
| |
| Publish("members of <group ID>", creator peer’s ID) |
|------------------------------------------------------>|
| OK |
|<------------------------------------------------------|
| |
| Publish("group list wildcard", group ID) |
|------------------------------------------------------>|
| OK |
|<------------------------------------------------------|
| |
公共群组创建
图2
离开一个群组使用的是基本P2P协议的离开功能离开相应的组层次网。将要离开的节点必须也要停止更新它在主层次网的群组成员发布信息,如果可能的话删除在主层次网中的存在形式。如果离开的节点还担当了组层次网中的一个对等体位置,离开的时候还应当很自然的撤销其维护功能性。
Joining Peer Main Ov. Boots. Peer Group Ov.
| | | |
| Lookup(group ID) | | |
|------------------------------->| | |
| Group info | | |
|<-------------------------------| | |
| | | |
| New stack instance | | |
|------+ | | |
|<-----+ | | |
| | | |
| Bootstrap request | | |
|------------------------------------------->| |
| OK | | |
|<-------------------------------------------| |
| | | |
| Join overlay | | |
|------------------------------------------------------->|
| OK | | |
|<-------------------------------------------------------|
| | | |
| Publish("members...", peer ID) | | |
|------------------------------->| | |
| OK | | |
|<-------------------------------| | |
| | | |
加入一个公开群
图3
在P2P网络中提出使用指针在网外来引用一个特定的层次网或资源。在组管理中,指针可以用来指到特定的群组。例如,一个基于指针指向一个组的“链接”可以在邀请一个新成员使用。开启“链接”就会促发DHT协议栈的实例化和P2P协议的加入操作。
4.4.群组移除
移除一个群组是通过关闭群组网实现以达到没有节点再存在。群组和成员信息应当从主层次网中移除。即要移除:1)资源(键值对),键是群组ID;2)列表里的群组,列表包含在键是通配符的资源里面;3)成员资源,它的键是“群ID的成员”。
组层次网也可以停止存在甚至不需要显式群组移除。如果没有对等体存在层次网中,例如只有客户端存在以及没有节点愿意扮演新对等体,群组就会消失。
4.5群组绑定到一个“别名”ID
我们可以为现有的群组使用别名操作。绑定操作通过向主层次网里发布一个键值对,用到的键是一个新的组ID(绑定ID,一个别名绑定到现存层次网上),值是标明是那个原始群组ID。这很类似于在在组创建时发布的键值对,但是取消掉群组信息,值仅仅是上面提到的信息。因此,当一个节点加入一个组是,通过识别一个绑定的ID就可以,对等体通过之得到相应原始的ID代表的群组信息。
绑定是很有用的,例如当创建一个基于位置的社区,里面定义位置的蓝牙和RFID标签的ID使用来计入现有群层次网;这种情况下绑定的ID将是蓝牙ID或者RFID标签ID。
5.数据格式
为了使对等体正确解析群组相关的信息,相关的存储DHT值(在键值对里面,它已在这篇文档不同群组操作中提到了)在这部分会定义相应的语法要求。
XML用来对在资源值中群组相关的信息进行编码。所有这些XML文档都会加上一个头“GROUP-MANAGEMENT:”(XML文档的外面),使得对等体可以从其他类型的资源里面识别群管理相关的资源,仅仅简单检查是否资源值。这也消除了当没有群组相关时去进行XML解析。未来,可能会使用MIME类型替代目前使用的类型标识符“GROUP-MANAGEMENT:”头。
在所有这些XML文档中,根标签是“group_management”。这个根标签有一个属性叫做“type”,用以表明怎样识别内部元素。在组信息中(组创建时发布的),属性值是“group_info”。在组绑定中,属性值是“group_id_redirect”。这样当加入一个群组时,加入的对等体可以决定是否发现的XML资源直接包括相应的群组信息(组ID作为查询主键),或者它是否包含一个边界组真实ID,当然这就又需要查询操作以便发现该群组的组信息(绑定ID作为查询键)。
下面的XML文档是一个发布群组信息的例子。
GROUP-MANAGEMENT:
<group_management type="group-info">
<bootstrap-address>12.34.56.78</bootstrap-address>
<bootstrap-port>5080</bootstrap-port>
<description>The most jolly group!</description>
</group_management>
下面是一个展示发布的绑定的XML文档。当一个使用绑定ID作为查询主键查询执行的时候,这个资源值被发现了。属性“encoding”的值可以是“as-is”,表明被包含的组ID(可能是人可读的)可以使用来找寻真实组信息,或“hex”,这表示包含的组ID是以十六进制字符的形式编码的,没字节两个十六进制字符。
GROUP-MANAGEMENT:
<group_management type="group-id-redirect">
<actual-group-id encoding="hex">0276EC1F</actual-group-id>
</group_management>
用绑定的ID加入一个有ID的群组方式没有在这篇文档中涉及到。图3仅仅展示了组信息直接被找到的情况。
多谢每组的层次网设计,这样对特殊数据格式的需求能达到最小规模,因为组内部活动(通信,协作资源的发布等)是免于语法需求,从组管理看。这意味着没有必要打上标签表明这些资源术语这个组,因为所有特定组活动是自动包含在组层次网中,不会冒与其他层次网活动的冲突。
6.性能考虑
减轻目前节点在复杂网络环境下关系的优化技术被使用了。例如,为了减轻内存耗用,关于远程节点的路由信息可以在本地存储数据结构分享,这样避免了保持重复的远程节点信息。尽管如此,这种技术是可选的。一个简单的实现可以很容易利用目前运行着的P2P协议栈,它们还不是协调一致的。在这样一种情形—对等体是主层次网和一个组层次网成员,那种实现可以运行两种协议栈实体。
7.致谢
作者想要感谢美国哥伦比亚大学Henning Schulzrinne教授提供了有价值的评论。
8.IANA考虑
这个备忘录目前还未向IANA请示。
9.安全考虑
介绍的组管理机制有效地囊括了在组层次网中的特定组流量,因此可以帮助我们提高安全和隐私。不过,紧接着的问题是,比如怎么确定只有合法的用户可以加入特定的组。未来的工作包括安全组访问管理发展机制。
11. 参考文献
10.1.常规参考
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2.报告参考
[FACEBOOK]
"Facebook", <http://www.facebook.com/>.
[GOOGLEGRP]
"Google Groups", <http://groups.google.com/>.
[HIERAS] Xu, Z., Min, R., and Y. Hu, "HIERAS: A DHT Based
Hierarchical P2P Routing Algorithm", 2003, <http://
ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1240580>.
[HierarchP2P]
Garc’es-Erice, L., Biersack, E., Felber, P., Ross, K., and
L. Urvoy-Keller, "Hierarchical Peer-to-Peer Systems",
2003, <http://www.springerlink.com/content/
4cratlwjx1075pnx/fulltext.pdf>.
[I-D.hardie-p2psip-p2p-pointers]
Hardie, T. and V. Narayanan, "Pointers for Peer-to-Peer
Overlay Networks, Nodes, or Resources", internetdraft
hardie-p2psip-p2p-pointers-01, March 2009.
[JXTA] Gong, L., "Project JXTA: A Technology Overview", 2001, <ht
tp://admis.fudan.edu.cn/member/yztang/Papers/P2P/industry/
JXTA%20TechOverview.pdf>.
[P2PSIP] "Peer-to-Peer Session Initiation Protocol (P2PSIP) IETF
Working Group",
<http://ietf.org/html.charters/p2psip-charter.html>.
[YAHOOGRP]
"Yahoo Groups", <http://groups.yahoo.com/>.
作者地址
Otso Kassinen
University of Oulu
Erkki Koiso-Kanttilan katu 3
University of Oulu, 90014
Finland
Phone: +358 8 553 2811
Email: otso.kassinen@ee.oulu.fi
Timo Koskela
University of Oulu
Erkki Koiso-Kanttilan katu 3
University of Oulu, 90014
Finland
Phone: +358 8 553 2522
Email: timo.koskela@ee.oulu.fi
Erkki Harjula
University of Oulu
Erkki Koiso-Kanttilan katu 3
University of Oulu, 90014
Finland
Phone: +358 8 553 2522
Email: erkki.harjula@ee.oulu.fi
Mika Ylianttila
University of Oulu
Erkki Koiso-Kanttilan katu 3
University of Oulu, 90014
Finland
Phone: +358 8 553 25311
Email: mika.ylianttila@ee.oulu.fi