GENI的三层体系架构

　　整个GENI的体系结构被分成三个层次，在文中表示为物理底层、用户服务和GMC(GENI Management Core，GENI的管理核心)。

　　在最底层，GENI提供了一套物理设施(如路由器、处理器、链路、无线设备)，我们称其为物理底层。底层的设计是为了确保物理资源、布局和互联拓扑足以支持GENI的研究目标。

　　在顶层，GENI的用户服务提供了一套丰富的用户可见的支持服务，旨在让底层设施实现可访问，而且满足研究的目标。伴随研究人员需求的变化以及GENI复杂性的提升，我们希望这套用户服务也会发生变化和发展。整个GENI体系结构的一个关键目标就是能让这些服务在整个设施的生命期中不断发展。

　　在物理底层和用户服务之间，是GENI管理核心，简称GMC。GMC的目的在于定义一个稳定的、可预知的、长期的框架——抽象层、接口、命名空间以及核心服务——以便将GENI体系结构绑定在一起。因为GENI的物理底层和用户服务都会伴随设施的建设和使用而快速地发展和进化，所以，GMC在设计时就需要定义一套瘦小的机制，从而既能支持和促进发展，又能将系统不同部分的变化隔离开来，以使独立地发展成为可能。

　　通过分析现有互联网的体系结构，可知GENI的体系结构是与沙漏模型相吻合的：GMC对应IP层以及它的编址路由和服务模型(我们将其定义为GENI沙漏的“细腰”)；而上层的管理服务对应于那些附加的用于将Internet系统完整化的功能(如HTTP，WWW，SKYPE)；GENI的底层则对应一套构造物理Internet的计算和网络设施。本文重阐述定义GMC的最初设计，但同时又勾勒出整个GENI体系结构的框架。

　　为了从功能上来描述GENI，必须把GMC缩减为一个特定的实现。这个实现称作GENI管理核心实现(简称GMCI)。GMCI为整个GENI系统提供了两个关键元素，这就是一小套系统运行所需要的核心服务，以及一个下层的通信和远程操作调用框架，以便让GENI的元素彼此通讯。GMCI的一大重要性，在于它可以让不同的功能实现，为不同版本的非核心态用户服务，使之轻松地加入系统。

　　值得注意的是，GMC并不是一套管理服务或者说操作中心，它只是定义了一个可以实现这些管理服务或操作的框架。

　　同样，我们需要区分狭义的作为NSF设施建设项目的GENI(我们称其为“GENI proper”或者 “NSF GENI”)，与更大规模的联盟化的GENI设施(我们称其为“GENI生态系统”)。本文定义的GMC是从GENI生态系统的角度说的(比如GMC明确地支持联盟)，尽管我们经常用NSF资助的项目来描述GENI体系结构的某些方面。

　　GMC涉及的玩家

　　GMC涉及不同类别的用户和组织：
　　部分底层的拥有者。他们要对设备的外部行为负责，而且要为他们这部分底层的使用制定政策。
　　部分GENI的管理员。他们为上述拥有者服务，或者隶属于GENI。他们的任务是保证平台的运行，为研究人员提供服务，并防止恶意的或者损坏性的活动破坏平台。
　　基础设施服务的开发人员。他们在GMC功能的基础上，为GENI社区实现通用服务。
　　使用GENI的研究人员。他们用GENI进行、运行实验、部署试验性服务或测量等。
　　不附属于GENI的终端用户。但他们使用了GENI上运行的研究项目提供的服务。
　　困惑或关心GENI上运行试验效果的人。因为他们自己的产业可能是受到影响的第三方。
　　GMC并不直接满足这些群体的需求，事实上很多用户会通过中介服务与底层打交道。取而代之的是，我们可以把GMC的目标划分成支持这些高级服务的不同活动。

　　GMC可控可扩展的行为

　　基于上述的玩家，我们确定了GMC必须进行的活动：

　　第一，允许拥有者声明掌控底层设施的资源分配和使用策略，并且提供一套机制保证这那些策略实施。

　　第二，允许管理员管理GENI的底层，包括安装新的物理设备，淘汰老损的设备，安装或更新系统软件，以及监测GENI的性能、功能和安全性。另外，管理必须分开化，必须有多于一个的机构管理分离的GENI站点。这样，既能让个人管理自己的机器，也要让一些大机构联合起来大粒度地管理。

　　第三，允许研究人员建立和推广，充分为他们分配资源以及运行试验软件。例如方便地安装库或运行时语言，这有可能由上层服务来提供的。在这种情况下，GMC的目标是支持这样的服务。同时，GMC应该为研究人员的应用、试验和服务提供一个执行环境。这些执行环境必须是灵活的(比如支持一套宽泛的程序行为)，并且运转良好。

　　第四，将GENI底层的信息暴露给开发人员。这样他们就可以实施高层的监控、测量、审计和资源发现服务。从某种意义上来说，GMC可以被认作GENI这个分布式系统的模拟核心，所以，在可控的前提下，应该把信息暴露给那些管理系统，以高效使用或者科学地观察其服务。

　　GENI的一个中心目标就是提供一套接口，通过它，研究人员可以请求资源，拥有者可以按照对这些资源的限制来制定策略。这些请求/限制包含如下内容：

　　资源：可以请求/限制用户试验消耗的处理器、存储、内存以及网络资源的量。

　　特权：可以请求/限制试验可以调用的特权操作。比如访问测量传感器，以及基础设施服务读写系统状态的权力。

　　包含：可以请求/限制一个试验怎样与网络的其它部分交互。比如一个试验用什么样的地址和端口与现有的Internet连接，向某个特定地址发包的速率，以及可以生成的包的类型。

　　GMC命名采用自认证方式

　　GMC定义了一种清晰的命名方法来为各种对象命名(例如用户、组件、集合slice)。GENI的命名系统用自认证的方式，从而简化了名字解析进程。注意：这节对命名的描述都是抽象的，更多细节信息会在其他地方提出。

　　GENI的命名是自验证的数据结构，包括类型信息和目标身份。这个名字可以是一个签名的数据结构，展示了对象的类型和特殊的标识，例如type=component，id=0xdeadbeef。如果这个数据结构被一个有效的GENI权威机构(比如一个组件的拥有者，如果他的密钥被名字管理者拥有，就是一个有效的GENI权威机构)签名，则这个被签名的名字就是一个有效的GENI名字。这当然要求权威机构诚实守信，其信任关系是明确的。注意：同样的数据结构如果被不同的权威机构签署就会有不同的名字。

　　除了类型信息和身份信息，这个名字可能还拥有针对名字普通用途的信息。比如，一个对象名称可能包含一个联系对象管理者的URI，或者是联系授权访问这个对象的权威机构的URI。因为这个信息是被签名的，对附加信息的修改会改变对象的名字，所以必需谨慎选择。特别是，这些信息的生存期必须与名字的生存期吻合。这种机制与将未证实的提示及系统各处关联起来的机制是截然不同的。

　　建立起名字的合法性显然依赖于使用这个名字的实体的信任关系。例如，一个用户可能认为一个本地认证的名字是合法的，而这个管理域之外的用户未必这样认为。

　　GENI将基于公私密钥队表达明确的命名权力委托，提供一个清晰的、分层的名字认证空间。因此，将会有一个顶级的命名权力机构，被所有的GENI实体认可。一个受认证的权力机构用认证密钥签署一个密钥对，并将它传递给新的权力机构来委派命名。这个新的权力机构就可以根据自认为合适的方式来信任关系。在任何情况下，每当提出一个GENI名字，名字所有者就可以顺着这个签署的密钥链，从签署名字的密钥，一直追溯到根权力机构以验证这个名字。

　　GMC为这个分层结构中的每个委派机构和名字分配了一个独一无二的字符串，这样，名字就可以用一种熟悉的、可读的方式表示：

　　top-level_autority.sub_authority.sub_authority.name

　　这个设计的一大特点在于，用来分派命名权力和证明名字的分层结构，并不需要与名字的解析者相同。用来解析名字或者在名字间做映射的系统并不一定要可信任，因为它们的解析结果是要被审核的。

　　用户可以联系一个与认证机构/权威机构不同的查找服务，以得到对象管理者的GENI名字。这种查找服务可以是中心数据库式的，或者是按照对象类型区分的不同于命名权力机构的命名服务。通过这种服务，用户获取到对象管理者的GENI名字之后，可以验证这个名字指向一个有效的组件。用户可能直接与管理者联系以确认正确性，当然也可以把对象和管理者绑定做签名，但这样不够灵活。

　　因为用户不相信解析器，但相信经过验证的名字，所以很多解析器可以并存，而且可以专用于不同的管理域或问题域。因为他们并不需要被信任，所以他们可以在不停用GMC的情况下移入和移出GENI。

　　并且，因为这种自验证属性并不依赖于上述命名空间的分层组织结构，所以其它的命名空间也可以与GENI的默认命名空间并存。一旦一个非层次化的认证空间或不同的层次结构被证明更高效，那么初始的那种认证层次结构将必然被替代。然而，我们注意到，任何一个基于受信网络而不是层次结构的名字空间，都需要名字授予者的信任链是惟一的，从而需要一个独立的名字分配机制。

　　名字分配信任关系与GMC中的其它信任关系也是不同的。使用GENI资源的权力可能与使用名字资源的权力源自不同的信任关系。例如，命名组件的权力可能属于一个系统管理员，而对它们的访问权力可能是由管理这个实验室的研究员或者由GENI的科学委员会来管理的。其实，不需要名字分配的层次结构与其它的层次结构不同，但如果将它们分开，这种灵活性将允许部署不同的服务，而且可以清晰地分派责任。

　　GMC抽象层

　　GMC定义的三个主要抽象层，即组件、切片和集合。下文描述了它们支持的接口。

　　组件

　　GMC将组件定义为GENI最初级的构件。例如一个组件可以指边界计算机、一个定制的路由器或者一个可编程的接入点。

　　一个组件包含了一套资源，包括物理资源(例如CPU，内存，硬盘和带宽)以及逻辑资源(比如文件描述符，端口号)，这些资源可以被包含在同一个物理设备中，或者分布在一套设备中，这取决于组件的特性。一个给定的资源则至多属于一个组件。

　　每个组件都是通过一个组件管理器(CM)控制的，它提供了一个定义好的、远程访问的接口。这个组件管理器抽象层定义了GMC的操作能力以及上层服务，将管理组件资源分配给不同用户和他们的实验的方式。

　　切片

　　一个slice对应于分布在一套GENI组件中的sliver，加上一些允许访问这些sliver以运行试验的关联的用户(研究者)。用户在GENI底层设施的一个切片上运行他们的试验。

　　一个slice拥有一个名字，和与之关联的用户集绑定。有一套sliver与slice关联，但GMC并不为slice定义一个具体的表述。取而代之的是，slice是由任何为某些用户创造这套sliver的服务定义的。

　　集合

　　集合是组件的无序集。它有一个标识，并且支持对集的通用操作(如增加，删除和编号)。集合为用户、开发人员或者管理员提供了一个方法，将一套GENI组件和一些软件定义的行为看成一个可标识的单元。

　　集合可以是层次结构的，也即集合中可以包含集合。

　　集合的例子可以是物理位置(在某个站点的所有组件)，集群(一些共享物理连接的组件)，一个权威机构(由某个权威管理的一群组件)，一个配置文件(一群共享配置信息的组件)，或者一个网络(实现骨干网或无线子网的一群组件)。同样可能有一个“根”集合对应于所有的GENI组件。

　　集合是一个活动的对象，可以接受和拒绝对它的调用操作。这些操作是由(AM)集合管理器实现的。类似于组件和组件管理器，一个集合可以有一个可区分的标识，以便CMCI调用对它的操作。这个标识可以被认作GMCI命名空间中的组件名称。

　　用户

　　GENI的用户创造和操作slice。每个用户是由一个证书和密钥对来标识的，这由一个GENI的权威机构来办理，以鉴定用户是否合法。在slice上操作的权力是与用户证书相关联的。

　　来源：《中国教育网络》