CN112866437A - 一种数据处理方法及域名解析架构 - Google Patents

Abstract

本申请涉及一种数据处理方法及域名解析架构，属于网络通信技术领域。该方法应用于联盟站点，方法包括接收来自TCP/IP网络的标识解析请求，并将标识解析请求转换为适用于NDN网络的数据请求，数据请求中包含有标识解析请求中的标识信息；基于标识信息判断本地是否能对数据请求进行解析；在确定本地无法对数据请求进行解析时，将数据请求发送至能解析标识信息的其他联盟站点，每个联盟站点负责解析的标识类型不同。通过将来自TCP/IP网络的标识解析请求，转换为适用于NDN网络的数据请求，从而将各标识体系的标识空间统一映射到NDN网络下的标识空间，使得可以直接支持应用程序对数据获取的需求，为用户提供多标识解析服务。

Description

一种数据处理方法及域名解析架构

技术领域

本申请属于网络通信技术领域，具体涉及一种数据处理方法及域名解析架构。

背景技术

在工业互联网等新型网络应用场景中，数据成为业务应用的中心，单一标识空间难以满足各行各业数据的多样性，多标识体系并存及互操作性成为新型标识解析体系建设的核心需求。目前的域名解析大都采用基于传输控制协议/网际协议(TransmissionControl Protocol/Internet Protocol，TCP/IP)互联网体系结构上以主机为中心的通信模型，主机作为运行应用程序的物理或虚拟设备，需要通过IP地址配置，转发配置，域名系统(Domain Name System，DNS)服务器设置和其他参数或协议配置后才能通信，难以“直接”支持应用程序对数据获取的需求。

发明内容

鉴于此，本申请的目的在于提供一种数据处理方法及域名解析架构，以改善当前TCP/IP互联网体系结构，难以直接支持应用程序对数据获取的需求，难以适应多标识体系并存的问题。

本申请的实施例是这样实现的：

第一方面，本申请实施例提供了一种数据处理方法，应用于联盟站点，所述方法包括：接收来自TCP/IP网络的标识解析请求，并将所述标识解析请求转换为适用于NDN网络的数据请求，所述数据请求中包含有所述标识解析请求中的标识信息；基于所述标识信息判断本地是否能对所述数据请求进行解析；在确定本地无法对所述数据请求进行解析时，将所述数据请求发送至能解析所述标识信息的其他联盟站点，其中，每个联盟站点负责解析的标识类型不同。本申请实施例中，通过将来自TCP/IP网络的标识解析请求，转换为适用于NDN网络的数据请求，然后基于标识信息判断本地是否能对数据请求进行解析，在确定本地无法对所述数据请求进行解析时，将数据请求发送至能解析该标识信息的其他联盟站点。该方案，将各标识体系的标识空间统一映射到NDN网络下的标识空间，使得可以直接支持应用程序对数据获取的需求，为用户提供多标识解析服务。

结合第一方面实施例的一种可能的实施方式，所述方法还包括：在确定本地能对所述数据请求进行解析时，调用本地接入的域名服务器对所述数据请求进行解析。本申请实施例中，在确定本地能对数据请求进行解析时，调用本地接入的域名服务器对数据请求进行解析，以保证解析的及时性。

结合第一方面实施例的一种可能的实施方式，所述联盟站点包括：标识交换点、根接入点和顶级接入点，调用本地接入的域名服务器对所述数据请求进行解析，包括：所述标识交换点在确定所述标识信息为根标识时，将所述数据请求发送至所述根接入点，以便调用所述根接入点接入的域名服务器对所述数据请求进行解析；所述标识交换点在确定所述标识信息为顶级标识时，将所述数据请求发送至所述顶级接入点，以便调用所述顶级接入点接入的域名服务器对所述数据请求进行解析。本申请实施例中，当联盟站点包括根接入点和顶级接入点时，在确定标识信息为根标识时，调用根接入点接入的域名服务器对数据请求进行解析，在确定标识信息为顶级标识时，调用顶级接入点接入的域名服务器对数据请求进行解析，以便于正确对该数据请求进行解析。

结合第一方面实施例的一种可能的实施方式，基于所述标识信息判断本地是否能对所述数据请求进行解析，包括：通过判断所述标识信息是否在本地数据标识前缀列表中来判断本地是否能对所述数据请求进行解析；其中，所述标识信息在所述本地数据标识前缀列表中，表示本地能对所述数据请求进行解析；相应地，所述联盟站点包括：标识交换点和域名接入点，通过判断所述标识信息是否在本地数据标识前缀列表中来判断本地是否能对所述数据请求进行解析之前，所述方法还包括：所述标识交换点接收所述域名接入点以数据标识前缀的形式发送的自身对接的域名服务器的标识，并维护本地数据标识前缀列表，以及将自身维护的本地数据标识前缀列表与其他联盟站点之间进行数据标识同步。本申请实施例中，标识交换点通过对域名接入点以数据标识前缀的形式发送的，域名接入点对接的域名服务器的标识进行存储，并维护本地数据标识前缀列表，以及将自身维护的本地数据标识前缀列表与其他联盟站点之间进行数据标识同步，使得可以通过判断标识信息是否在本地数据标识前缀列表中来判断本地是否能对数据请求进行解析，从而可实现快速判断本地是否能对数据请求进行解析。

结合第一方面实施例的一种可能的实施方式，所述方法还包括：接收对所述数据请求进行解析后返回的数据应答，所述数据应答中包含有所述标识信息；基于所述标识信息将所述数据应答转换为适用于TCP/IP网络的标识解析应答，并原路返回给用户。本申请实施例中，基于标识信息通过将对数据请求解析后返回的数据应答适用于TCP/IP网络的标识解析应答，并原路返回给用户，以保证方案的完整性。

第二方面，本申请实施例还提供了一种域名解析架构，包括：位于同一个NDN网络中的多个联盟站点，所述多个联盟站点依次连接，每个联盟站点负责解析的标识类型不同；针对每一个联盟站点，该联盟站点包括：站点收发中心、标识交换点；站点收发中心，用于接收来自TCP/IP网络的标识解析请求，并将所述标识解析请求转换为适用于NDN网络的数据请求，所述数据请求中包含有所述标识解析请求中的标识信息；标识交换点，用于基于所述数据请求中的标识信息判断本地是否能对所述数据请求进行解析；在确定本地无法对所述数据请求进行解析时，将所述数据请求发送至能解析所述标识信息的其他联盟站点。

结合第二方面实施例的一种可能的实施方式，该联盟站点还包括：用于连接域名服务器的域名接入点；在确定本地能对所述数据请求进行解析时，所述标识交换点，还用于将所述数据请求发送至所述域名接入点；所述域名接入点，用于调用所述域名服务器对所述数据请求进行解析。

结合第二方面实施例的一种可能的实施方式，所述域名接入点包括：用于连接根域名服务器的根接入点和用于连接顶级域名服务器的顶级接入点；所述标识交换点，具体用于在确定所述标识信息为根标识时，将所述数据请求发送至所述根接入点，以便调用所述根接入点接入的域名服务器对所述数据请求进行解析；在确定所述标识信息为顶级标识时，将所述数据请求发送至所述顶级接入点，以便调用所述顶级接入点接入的域名服务器对所述数据请求进行解析。

结合第二方面实施例的一种可能的实施方式，所述域名接入点还用于将自身对接的域名服务器的标识以数据标识前缀的形式发送给所述标识交换点进行保存；相应地，所述标识交换点，还用于维护本地数据标识前缀列表，以及将自身维护的本地数据标识前缀列表与其他联盟站点之间进行同步。

结合第二方面实施例的一种可能的实施方式，所述标识交换点，还用于接收对所述数据请求进行解析后返回的数据应答，所述数据应答中包含有所述标识信息；所述站点收发中心，还用于基于所述标识信息将所述数据应答转换为适用于TCP/IP网络的标识解析应答，并原路返回给用户。

本申请的其他特征和优点将在随后的说明书阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请实施例而了解。本申请的目的和其他优点可通过在所写的说明书以及附图中所特别指出的结构来实现和获得。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。通过附图所示，本申请的上述及其它目的、特征和优势将更加清晰。在全部附图中相同的附图标记指示相同的部分。并未刻意按实际尺寸等比例缩放绘制附图，重点在于示出本申请的主旨。

图1示出了本申请实施例提供的一种域名解析架构的结构示意图。

图2示出了本申请实施例提供的一种联盟站点的结构示意图。

图3示出了本申请实施例提供的一种联盟站点内各节点内部的结构示意图。

图4示出了本申请实施例提供的一种数据处理方法的流程示意图。

图5示出了本申请实施例提供的又一种数据处理方法的流程示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中诸如“第一”、“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

再者，本申请中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

鉴于当前TCP/IP互联网体系结构，难以“直接”支持应用程序对数据获取的需求，难以适应多标识体系并存的问题。本申请实施例提供了一种基于命名数据网络(NamedData Networking，NDN)的域名解析架构，为所有标识应用协议提供数据寻址和路由以及解析服务。该域名解析架构包括位于同一个NDN网络中的多个(两个及两个以上)联盟站点，多个联盟站点依次连接，每个联盟站点负责解析的标识类型不同。其中，该域名解析架构中包括的联盟站点的数量可以根据其应用场景的标识类型来决定，需要解析的标识类型越多，对应的联盟站点的数量越多。其中，每一个联盟站点相当于为一个数据标识网络(DataIdentifier Network，DIN)站点。

该域名解析架构包括的多个联盟站点依次连接，以该域名解析架构包括6个联盟站点为例，假设6个联盟站点分别为联盟站点1、联盟站点2、联盟站点3、联盟站点4、联盟站点5、联盟站点6，则一种可选实施方式下，这6个联盟站点依次连接可以是联盟站点1、联盟站点2、联盟站点3、联盟站点4、联盟站点5、联盟站点6依次连接，此外，联盟站点6还可以与联盟站点1连接，由此形成环形网络，其示意图如图1所示。其中，需要说明的是，图1示例的连接方式仅是众多连接方式中的一种，不能将其理解成是对本申请的限制。此外，多个联盟站点除了依次连接外，还可以采用全连接的方式进行连接，也即每个联盟站点均与剩余的联盟站点连接。

其中，联盟站点与各标识解析系统的用户及权威数据源直接进行数据交换，为用户提供由域名解析架构支撑的多标识解析服务。如图2所示，每个联盟站点则由多个扮演不同功能角色的节点组成，针对每一个联盟站点，该联盟站点包括：站点收发中心、标识交换点以及域名接入点。

站点收发中心，作为域名解析架构的数据入口，向外部提供各类标识解析服务。站点收发中心，用于接收来自TCP/IP网络的标识解析请求，并将标识解析请求转换为适用于NDN网络的数据请求，其中，数据请求中包含有标识解析请求中的标识信息。例如，在来自TCP/IP网络的标识解析请求中添加该标识信息的标识前缀，将其转换为数据请求。其中，标识解析请求是来自互联网(TCP/IP网络)的客户请求数据，而数据请求是域名解析架构内将标识解析请求添加特殊标识(如标识前缀)后，得到的新的数据解析请求，目的是方便节点(如站点收发中心、标识交换点)分辨数据是来自互联网还是联盟内部路由。例如，标识解析请求为www.foo.ru的解析请求，则将可以通过添加标识前缀：/DNS/RU，将其转换为数据请求。

标识交换点，用于基于数据请求中的标识信息判断本地是否能对该数据请求进行解析，在确定本地无法对数据请求进行解析时，将数据请求发送至能解析标识信息的其他联盟站点；在确定本地能对数据请求进行解析时，标识交换点，还用于将数据请求发送至本地的域名接入点。其中，标识交换点会维护本地数据标识前缀列表，并参与数据标识网络路由，将自身维护的本地数据标识前缀列表与其他联盟站点之间进行同步，进而指导数据请求的转发，将其正确转发到能对其进行解析的本地域名接入点或其他联盟站点。由于各个联盟站点之间会进行数据标识同步，联盟站点根据数据请求中的标识信息，便可找到能解析该标识信息的其他联盟站点。以图1所示的域名解析架构为例，假设接收标识解析请求的为联盟站点1，能解析该标识信息的联盟站点为联盟站点3，则联盟站点1在根据各个联盟站点之间同步的数据标识确定联盟站点3可以解析该标识信息时，则根据其连接关系将该数据请求发送给联盟站点2，再由联盟站点2发送给联盟站点3进行解析。

其中，标识交换点在基于数据请求中的标识信息判断本地是否能对该数据请求进行解析时，可以是通过判断标识信息是否在本地数据标识前缀列表中来判断本地是否能对数据请求进行解析，其中，该标识信息在本地数据标识前缀列表中，表示本地能对该数据请求进行解析。

域名接入点，用于对接域名服务器，在接收到标识交换点发送的数据请求时，调用自身对接的域名服务器(如DNS、Handle、对象标识符(Object Identifier，OID))对该数据请求进行解析。其中，域名接入点对接域名服务器，用于将域名服务器的标识(如“标准名称”或标识域)以数据标识前缀的形式(如声明/Handle/前缀、声明/DNS前缀、声明/OID前缀、声明/DNS/CN前缀、声明/DNS/RU前缀、声明/Handle/10前缀等)注册到本地的标识交换点，由标识交换点进一步声明到整个域名解析架构。以及，域名接入点还用于接收所注册数据标识前缀下的数据请求，并调用自身对接的域名服务器对该数据请求进行解析，并向标识交换点返回包含标识信息的数据应答。

可选地，标识交换点，还用于接收对所述数据请求进行解析后返回的数据应答，所述数据应答中包含有所述标识信息。所述站点收发中心，还用于基于所述标识信息将所述数据应答转换为适用于TCP/IP网络的标识解析应答，并原路返回给用户。

其中，域名接入点可以用于连接根域名服务器(如DNS、Handle等)，此时，域名接入点相当于根接入点；域名接入点也可以用于连接顶级域名服务器(如DNS下的CN域、RU域、Handle下的10域)，此时，域名接入点相当于顶级接入点。一种实施方式下，可选地，域名接入点包括：用于连接根域名服务器的根接入点和用于连接顶级域名服务器的顶级接入点。相应地，标识交换点，在确定本地能对数据请求进行解析时，具体用于在确定标识信息为根标识(如/Handle/前缀、/DNS前缀、/OID前缀)时，将数据请求发送至根接入点，以便调用根接入点接入的域名服务器对该数据请求进行解析；在确定标识信息为顶级标识(如/DNS/CN前缀、/DNS/RU前缀、/Handle/10前缀)时，将数据请求发送至顶级接入点，以便调用顶级接入点接入的域名服务器对该数据请求进行解析。

其中，可选地，如图3所示，站点收发中心可以包括服务模块和转换模块。服务模块对外开放标识协议约定的端口，以接收外部(TCP/IP网络)的标识解析系统(如DNS)发送的标识解析请求，由转换模块根据与标识体系对应的转换方案，将标识解析请求转换为适用于NDN网络的数据请求，并在收到数据应答后，根据该转换方案，将数据应答转换为适用于TCP/IP网络的标识解析应答经服务模块发回给用户。

可选地，标识交换点包括：前缀注册模块和路由模块，前缀注册模块，负载接收和验证本地域名接入点发送的前缀注册请求，生成前缀列表输入给路由模块。路由模块采用链路状态路由协议，维护标识交换点间邻接关系，以及本地域名接入点声明的数据标识前缀，维护本地数据标识前缀列表，并参与数据标识网络路由，与其他标识交换点同步一个链路状态数据库，以计算数据标识前缀路由表，进而指导数据请求的转发，更新数据请求转发信息。

其中，可选地，根接入点或顶级接入点可以包括接入模块和解析模块。接入模块与域名服务器对接，处理报备信息，以更新解析模块中数据，以使其提供的标识信息与报备信息一致，此外，还用于告知解析模块需注册的数据标识前缀。将域名服务器的标识(如“标准名称”或标识域)以数据标识前缀的形式经解析模块注册到本地标识交换点，并由标识路由器进一步声明到整个域名解析架构。解析模块接收所注册数据标识前缀下的数据请求，由解析模块调用接入模块对应的域名服务器处理收到的数据请求，并发回包含标识信息的数据应答。其中，根接入点向标识交换点发送的前缀注册请求中的标识前缀为：声明/Handle/前缀、声明/DNS前缀、声明/OID前缀等，顶级接入点向标识交换点发送的前缀注册请求中的标识前缀为：声明/DNS/CN前缀、声明/DNS/RU前缀、声明/Handle/10前缀等。

本申请实施例中，各类型标识解析请求通过站点收发中心转换为数据请求，在域名解析架构内路由或转发，直到达到负责相应标识解析的域名接入点，解析成功后生成数据应答，并按原路返回，并在站点收发中心转换为适用于TCP/IP网络的标识解析应答，完成对标识的解析。该方案，将各标识体系的标识空间统一映射到域名解析架构内的标识空间，将标识解析请求转换为对域名解析架构中数据的请求。利用本申请提供的域名解析架构，可以在多标识体系并存的工业互联网等新兴网络应用场景中，应用程序和网络使用相同的命名空间：应用程序使用结构化名字创建数据并使用结构化名字请求数据，相同名字用于将请求定向到NDN网络，并将请求发送到负责相应标识解析的域名接入点。NDN网络“理解”应用程序使用的名字，即网络知道如何使用数据名字转发请求，从而实现数据粒度的寻址、路由、转发、缓存、加密、认证和访问控制。

本申请实施例还提供了一种应用于联盟站点中的数据处理方法，下面将结合图4，对本申请实施例提供的数据处理方法进行说明。

步骤S101：接收来自TCP/IP网络的标识解析请求，并将所述标识解析请求转换为适用于NDN网络的数据请求。

可选地，联盟站点中的站点收发中心作为联盟站点的数据入口，向外部提供各类标识解析服务，用于接收来自TCP/IP网络的标识解析请求，并将所述标识解析请求转换为适用于NDN网络的数据请求，所述数据请求中包含有所述标识解析请求中的标识信息。

步骤S102：基于所述标识信息判断本地是否能对所述数据请求进行解析。

联盟站点中的标识交换点接收站点收发中心发送的数据请求，并基于所述标识信息判断本地是否能对所述数据请求进行解析。在确定本地无法对所述数据请求进行解析时，执行步骤S103，在确定本地能对所述数据请求进行解析时，执行步骤S104。

可选地，通过判断所述标识信息是否在本地数据标识前缀列表中来判断本地是否能对所述数据请求进行解析，其中，所述标识信息在所述本地数据标识前缀列表中，表示本地能对所述数据请求进行解析。相应地，在通过判断所述标识信息是否在本地数据标识前缀列表中来判断本地是否能对所述数据请求进行解析之前，该方法还包括：标识交换点接收联盟站点中的域名接入点以数据标识前缀的形式发送的自身对接的域名服务器的标识，并维护本地数据标识前缀列表，以及将自身维护的本地数据标识前缀列表与其他联盟站点之间进行数据标识同步。

步骤S103：将所述数据请求发送至能解析所述标识信息的其他联盟站点。

在确定本地无法对所述数据请求进行解析时，将所述数据请求发送至能解析所述标识信息的其他联盟站点，其中，每个联盟站点负责解析的标识类型不同。

由于各个联盟站点之间会进行数据标识同步，联盟站点根据数据请求中的标识信息，便可找到能解析该标识信息的其他联盟站点。

步骤S104：调用本地接入的域名服务器对所述数据请求进行解析。

在确定本地能对所述数据请求进行解析时，调用本地接入的域名服务器对所述数据请求进行解析。

其中，可选地，当域名接入点包括根接入点和顶级接入点时，则调用本地接入的域名服务器对所述数据请求进行解析的过程可以是，标识交换点判断该标识信息是否为根标识，标识交换点在确定所述标识信息为根标识时，将所述数据请求发送至所述根接入点，以便调用所述根接入点接入的域名服务器对所述数据请求进行解析；所述标识交换点在确定所述标识信息为顶级标识时，将所述数据请求发送至所述顶级接入点，以便调用所述顶级接入点接入的域名服务器对所述数据请求进行解析。

可选地，所述方法还包括：接收对所述数据请求进行解析后返回的数据应答，所述数据应答中包含有所述标识信息；基于所述标识信息将所述数据应答转换为适用于TCP/IP网络的标识解析应答，并原路返回给用户。

为了便于理解上述的数据处理过程，可以参阅图5所示的数据处理流程图。

本申请实施例所提供的方法，其实现原理及产生的技术效果和前述域名解析架构实施例相同，为简要描述，方法实施例部分未提及之处，可参考前述域名解析架构实施例中相应内容。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.一种数据处理方法，其特征在于，应用于联盟站点，所述方法包括：

接收来自TCP/IP网络的标识解析请求，并将所述标识解析请求转换为适用于NDN网络的数据请求，所述数据请求中包含有所述标识解析请求中的标识信息；

基于所述标识信息判断本地是否能对所述数据请求进行解析；

在确定本地无法对所述数据请求进行解析时，将所述数据请求发送至能解析所述标识信息的其他联盟站点，其中，每个联盟站点负责解析的标识类型不同。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在确定本地能对所述数据请求进行解析时，调用本地接入的域名服务器对所述数据请求进行解析。

3.根据权利要求2所述的方法，其特征在于，所述联盟站点包括：标识交换点、根接入点和顶级接入点，调用本地接入的域名服务器对所述数据请求进行解析，包括：

所述标识交换点在确定所述标识信息为根标识时，将所述数据请求发送至所述根接入点，以便调用所述根接入点接入的域名服务器对所述数据请求进行解析；

所述标识交换点在确定所述标识信息为顶级标识时，将所述数据请求发送至所述顶级接入点，以便调用所述顶级接入点接入的域名服务器对所述数据请求进行解析。

4.根据权利要求1所述的方法，其特征在于，基于所述标识信息判断本地是否能对所述数据请求进行解析，包括：

通过判断所述标识信息是否在本地数据标识前缀列表中来判断本地是否能对所述数据请求进行解析；

其中，所述标识信息在所述本地数据标识前缀列表中，表示本地能对所述数据请求进行解析；

相应地，所述联盟站点包括：标识交换点和域名接入点，通过判断所述标识信息是否在本地数据标识前缀列表中来判断本地是否能对所述数据请求进行解析之前，所述方法还包括：

所述标识交换点接收所述域名接入点以数据标识前缀的形式发送的自身对接的域名服务器的标识，并维护本地数据标识前缀列表，以及将自身维护的本地数据标识前缀列表与其他联盟站点之间进行数据标识同步。

5.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

接收对所述数据请求进行解析后返回的数据应答，所述数据应答中包含有所述标识信息；

基于所述标识信息将所述数据应答转换为适用于TCP/IP网络的标识解析应答，并原路返回给用户。

6.一种域名解析架构，其特征在于，包括：位于同一个NDN网络中的多个联盟站点，所述多个联盟站点依次连接，每个联盟站点负责解析的标识类型不同；

针对每一个联盟站点，该联盟站点包括：

站点收发中心，用于接收来自TCP/IP网络的标识解析请求，并将所述标识解析请求转换为适用于NDN网络的数据请求，所述数据请求中包含有所述标识解析请求中的标识信息；

标识交换点，用于基于所述数据请求中的标识信息判断本地是否能对所述数据请求进行解析；在确定本地无法对所述数据请求进行解析时，将所述数据请求发送至能解析所述标识信息的其他联盟站点。

7.根据权利要求6所述的域名解析架构，其特征在于，该联盟站点还包括：用于连接域名服务器的域名接入点；

在确定本地能对所述数据请求进行解析时，所述标识交换点，还用于将所述数据请求发送至所述域名接入点；

所述域名接入点，用于调用所述域名服务器对所述数据请求进行解析。

8.根据权利要求7所述的域名解析架构，其特征在于，所述域名接入点包括：用于连接根域名服务器的根接入点和用于连接顶级域名服务器的顶级接入点；

所述标识交换点，具体用于在确定所述标识信息为根标识时，将所述数据请求发送至所述根接入点，以便调用所述根接入点接入的域名服务器对所述数据请求进行解析；在确定所述标识信息为顶级标识时，将所述数据请求发送至所述顶级接入点，以便调用所述顶级接入点接入的域名服务器对所述数据请求进行解析。

9.根据权利要求7所述的域名解析架构，其特征在于，所述域名接入点还用于将自身对接的域名服务器的标识以数据标识前缀的形式发送给所述标识交换点进行保存；

相应地，所述标识交换点，还用于维护本地数据标识前缀列表，以及将自身维护的本地数据标识前缀列表与其他联盟站点之间进行同步。

10.根据权利要求6所述的域名解析架构，其特征在于，所述标识交换点，还用于接收对所述数据请求进行解析后返回的数据应答，所述数据应答中包含有所述标识信息；

所述站点收发中心，还用于基于所述标识信息将所述数据应答转换为适用于TCP/IP网络的标识解析应答，并原路返回给用户。

Images