CN113726577A - 基于应用和用户态协议栈的网络管理方法及网络架构 - Google Patents

基于应用和用户态协议栈的网络管理方法及网络架构 Download PDF

Info

Publication number
CN113726577A
CN113726577A CN202111019683.1A CN202111019683A CN113726577A CN 113726577 A CN113726577 A CN 113726577A CN 202111019683 A CN202111019683 A CN 202111019683A CN 113726577 A CN113726577 A CN 113726577A
Authority
CN
China
Prior art keywords
app
protocol stack
user mode
request
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202111019683.1A
Other languages
English (en)
Other versions
CN113726577B (zh
Inventor
李涛
张晨
汪硕
黄韬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Network Communication and Security Zijinshan Laboratory
Original Assignee
Network Communication and Security Zijinshan Laboratory
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Network Communication and Security Zijinshan Laboratory filed Critical Network Communication and Security Zijinshan Laboratory
Priority to CN202111019683.1A priority Critical patent/CN113726577B/zh
Publication of CN113726577A publication Critical patent/CN113726577A/zh
Application granted granted Critical
Publication of CN113726577B publication Critical patent/CN113726577B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2212/00—Encapsulation of packets

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开一种基于应用和用户态协议栈的网络管理方法及网络架构，其中，网络架构包括应用层、TCP层、网络层和控制器，TCP层和应用层之间设有ServiceIP层，应用层包括多个APP，在所述ServiceIP层部署至少一个用户态协议栈，用户态协议栈为一个以上的APP所使用。网络管理方法包括控制器接收来自任一APP发出的APP请求，APP请求通过对应的用户态协议栈发送给控制器；控制器对APP请求进行处理，并将处理结果反馈给对应的用户态协议栈，由对应的用户态协议栈将控制器的处理结果发送给对应的APP。本发明解决了APP的标识、接入和移动性等问题，而且用户态协议栈部署更加灵活，平台移植性强。

Description

基于应用和用户态协议栈的网络管理方法及网络架构
技术领域
本发明涉及互联网技术领域，具体涉及一种SDN场景下基于应用和用户态协议栈的网络管理方法及网络架构。
背景技术
随着网络设备、接入用户、用户APP的大规模使用，当前互联网发展使得传统面向用户的网络接口面临越来越多的挑战。
首先，传统的操作***socket接口，以IP地址+端口为定位符进行通信，随着地址或者端口的变化，带来了网络的震荡。就APP来说，不应该感知IP地址或者端口的变化。而且，目前采用IP地址作为socket的基本接口不可能做到身份隐藏。对于网络窃听者来说，在报文整个传输中，总是可以根据IP地址身份追溯到源，从而发起相应的攻击。
第二，目前内核网络连接机制采用基于IP地址+端口的方式，无法区分不同的应用，也就无法进行应用的策略管理，导致网络数据冗余传输，极大浪费了网络资源。
第三，目前高优先级的应用需求没有一种方式合理的传递到网络层，因此基于应用的需求无法在网络上表达。导致不同的应用对于网络需要不一样，有的需要较高优先级调度、有的需要保证较好的传输质量，目前网络协议栈如FreeBSD等都是基于socket的公平调度，缺乏一种差异化基于应用的对应开放的网络接口。
目前针对应用的设计及区分，业界做了一定的研究工作，如主机标识协议(HIP，Host Identifier Protocol)，HIP对应用的编程API接口进行了一级抽象，由IP+端口改为HostID+端口的方式进行，使得应用编程可以基于恒定的Host ID+port进行。但是HIT采用改造内核协议栈的方式，基于内核的改造涉及内核版本的巨大差异化问题难以推广，同时由于内核协议栈的天然低效率、时延高、无应用APP的SLA适配API等特征使得该技术实际意义不大。而且不同的应用需要的网络资源是不同的，HIP注重主机身份与定位的分离，但是分离后，需要针对多身份不同的应用做策略控制。
发明内容
技术目的：针对现有技术中的不足，本发明公开了一种基于应用和用户态协议栈的网络管理方法及网络架构，其提出了一种用户态协议栈的API接口的设计方法，针对多APP接入场景下，通过控制器分配的ServiceIP进行应用APP通信；该API接口涉及网络感知应用的SLA需求、CS模式的服务发布、策略控制、报文收发等功能API接口。
技术方案：为实现上述技术目的，本发明采用了如下技术方案：
一种基于应用和用户态协议栈的网络管理方法，其特征在于：所述方法应用于网络架构，网络架构包括应用层、TCP层、网络层和控制器，TCP层和应用层之间设有ServiceIP层，应用层包括多个APP，在所述ServiceIP层部署至少一个用户态协议栈，用户态协议栈为一个以上的APP所使用；
所述方法包括步骤：
S1.控制器接收来自任一APP发出的APP请求，APP请求通过对应的用户态协议栈发送给控制器；
S2.控制器对APP请求进行处理，并将处理结果反馈给对应的用户态协议栈，由对应的用户态协议栈将控制器的处理结果发送给对应的APP。
优选地，在所述APP请求为业务注册请求时，所述步骤S2具体为：
控制器通过用户态协议栈接收APP发送的包含ServiceName、Domain、SubServiceID字段的ServiceIP注册请求，根据请求信息组装ServiceIP，经用户态协议栈下发到APP上；
控制器将得到的ServiceIP发送给其他用户态协议栈或转发面。
优选地，在所述APP请求为服务发布请求时，所述步骤S2具体为：
发出服务发布请求的APP作为服务端，通过对应的用户态协议栈向控制器发送服务发布请求，服务发布请求包括本地策略路由和协议栈ServiceIP表，本地策略路由包括指定发布策略，在指定发布策略中指定访问的黑白名单、访问策略；
控制器整合接收到的全局内所有服务发布请求，生成相应的全局策略路由，然后向对应的用户态协议栈返回发布成功消息，通告全局策略路由；
控制器将ServiceIP和策略路由通知其他协议栈或转发面。
优选地，所述服务发布请求为URL资源发布请求，APP通过对应的用户态协议栈向控制器发出服务发布请求中还包括URL，控制器生成的全局策略路由中包括URL与协议栈ServiceIP表的映射关系，URL变化由控制器通知到其他用户态协议栈或转发面。
优选地，在所述APP请求为连接或收发请求时，所述步骤S2具体为：
发出连接或收发请求的APP作为客户端；连接或收发请求中指定应用对网络的SLA需求，SLA需求用于标识App服务等级；作为客户端的APP发起一个到目的URL的知名地址的连接，并在连接属性中设置对网络的SLA需求；
对应的用户态协议栈将APP的连接需求发送至控制器进行算路；
控制器整合所有SLA需求，从全局角度进行网络层资源计算和优化，计算网络隧道并下发至网络层转发面，并告知对应的用户态协议栈算路结果；
客户端由用户态协议栈发送URL的报文请求，由用户态协议栈完成ServiceIP层封装之后，发送给转发面进行网络隧道封装；
经过封装的报文请求在到达服务端前，由转发面解封装网络隧道、由服务端的用户态协议栈解封装ServiceIP层，然后到达服务端的APP。
优选地，在所述APP请求为报文收发请求时，所述步骤S2具体为：
源APP在对应的用户态协议栈上面完成策略查找，策略查找通过后，对报文收发请求进行ServiceIP层封装；
在转发面上基于ServiceIP查找对应的源网络隧道和目的网络隧道，完成网络隧道的封装；
经过封装的报文请求在到达目的APP前，由转发面解封装网络隧道、由目的APP的用户态协议栈解封装ServiceIP层，然后到达目的APP。
优选地，所述ServiceIP采用IPV6地址的格式，选择性添加扩展头，扩展头中携带APP的源端到目的端的私有化信息。
优选地，所述SerivceIP包括0xfd、ServiceType、ServiceID、SubServiceID和InstanceID五种字段，其中，
0xfd长度用于标识一个ULA地址；
ServiceType用于标识ServiceAPP的类型；
ServiceID由控制器全局分配，用于标识相同ServiceType下的Service的ID，一个Service对应全局惟一的一个ServiceID；
SubServiceID用于标识相同ServiceID下的不同子服务的ID。
InstanceID用于标识不同服务实例；控制器根据ServiceIP申请请求中是否携带Domain字段来决策扁平化或者全局化分配InstanceID。
一种网络架构，包括应用层、TCP层、网络层和控制器，应用层包括多个APP，其特征在于：
所述应用层和TCP层之间设有ServiceIP层，用于为APP进行ServiceIP编址；
所述ServiceIP层部署一个以上的用户态协议栈，用户态协议栈为一个以上的APP所使用，用户态协议栈中存有本地ServiceIP表项和全局ServiceIP表项；
所述控制器用于接收任一APP发出的APP请求，APP请求通过对应的用户态协议栈发送给控制器；
控制器对APP请求进行处理，并将处理结果反馈给对应的用户态协议栈，由对应的用户态协议栈将控制器的处理结果发送给对应的APP；
ServiceIP层用于接收APP发出的业务注册或者去注册请求，向控制器申请为对应的APP注册对应的ServiceIP或者注销ServiceIP。
优选地，所述APP和用户态协议栈之间定义用于数据传递的对外API接口，对外API接口包括注册APP的ServiceIP地址的API接口、注销APP的ServiceIP地址的API接口、服务发布的API接口、取消服务发布的API接口、感知APP请求的API接口、屏蔽APP请求的API接口、发送报文的API接口、接收报文的API接口。
优选地，所述SerivceIP包括0xfd、ServiceType、ServiceID、SubServiceID和InstanceID五种字段，其中，
0xfd用于标识一个ULA地址；
ServiceType用于标识ServiceAPP的类型；
ServiceID由控制器全局分配，用于标识相同ServiceType下的Service的ID，一个Service对应全局惟一的一个ServiceID；
SubServiceID用于标识相同ServiceID下的不同子服务的ID。
InstanceID用于标识不同服务实例；控制器根据ServiceIP申请请求中是否携带domain字段来决策扁平化或者全局化分配InstanceID。
有益效果：本发明基于SDN场景，引入基于应用的用户态协议栈和基于该协议栈的基于应用的API接口。主要解决了以下几个技术问题：
(1)解决应用的标识问题：本发明基于TCP层之上定义了一个新的层取名ServiceIP层，用来标识整个应用的编址；设计了一套基于应用的用户态协议栈，基于该协议栈和对外API接口可以对基于应用的标识进行注册、查询、安全、寻址等功能的实现，同时该协议栈作为应用与网络的通道，负责了应用SLA需求的API接口的实现及应用SLA需求与网络交互，同时将结果反馈给应用。
(2)解决应用的接入问题：传统基于内核的协议栈接口基于IP+端口的模式进行开发，缺少基于应用的灵活性和的实用性，因此基于用户态协议栈设计一套基于应用的API接口，可以解决应用的接入需求，完成基于应用的Overlay连接、基于应用的需求表达等特性。
(3)解决应用的移动性问题：ServiceIP与服务报文类型无关，全局唯一；一个ServiceIP可以发布单播、组播、任播的服务，也可以不发布服务，***的ServiceIP层改变上层应用的编码规则；不再以IP地址+端口为socket关键字bind，以ServiceIP进行connect，保证IP地址无关性，维护一张ServiceIP与Domain的映射表、ServiceIP与IP映射表，当ServiceIP位置发生变化时，重新注册上线后，刷新该表即可，从而解决了移动性问题。
(4)用户态协议栈部署灵活，平台移植性强：因为是用户态协议栈，所以整个协议栈可以非常灵活的部署使用，应用可以使用原有的操作***SOCKET接口，也可以选择使用协议栈的新的接入接口。可以实现逐步切换，不影响整个平台的稳定性。
附图说明
图1为本发明中ServiceIP编址格式的示意图；
图2为本发明方法中的网络架构的全局结构示意图；
图3为本发明方法中ServiceIP的申请的流程示意图；
图4为本发明方法中Service服务发布功能的流程示意图；
图5为本发明方法中Service的连接功能及收发功能的流程示意图；
图6为本发明方法中报文收发功能的流程示意图。
具体实施方式
下面结合附图对本发明作详细的说明。
本发明基于SDN场景，基于TCP层之上定义了一个新的层取名ServiceIP层，用来标识整个应用层中APP的编址；设计了一套基于应用的用户态协议栈，和基于该协议栈的基于应用的API接口，基于该协议栈和对外API接口可以对基于应用的标识进行注册、查询、安全、寻址等功能的实现，同时该协议栈作为应用与网络的通道，负责了应用SLA需求的API接口的实现及应用SLA需求与网络交互等，同时将结果反馈给应用。如图2所示，本发明中基于应用的用户态协议栈位于ServiceIP层，网络中每个设备设有一个用户态协议栈，设备中具有一个以上的应用APP，ServiceIP层为用户服务，紧邻应用层，TCP层和网络层为传统网络。现有技术中用户APP直接用TCP层的API，即操作***接口，本发明中API接口设置在TCP层之上，使用ServiceIP层的对外API接口，用于精细化区分业务与应用。
一、应用的编址
本发明应用针对APP进行编址，得到的ServiceIP的格式，如图1所示。
前八位为0xFD，标识一个ULA地址；
ServiceType：标识ServiceAPP的类型，如聊天、视频、语音、在线游戏等大的类型，共可以标识256个不同Service类型；
ServiceID：标识在某个类型下Service的ID，32位，可以标识2^32个Service，为控制器全局分配，全局唯一；例如，聊天type下的微信即为一个ServiceID。
SubServiceID：标识相同Service下不同子服务；相同Service下可以有2^16个不同子服务；ServiceID下属的子服务类型，如微信下属服务有聊天、支付、相册等不同子服务。
Instance：该字段为可变字段。共64位，例如针对单播，有扁平化和层次化方案，如果是扁平化方案，InstanceID为一个User下使用的实例ID，为控制器统一全局下发；如果是层次化方案，里面可以嵌入域Domain概念，暂定20位，标识不同域，Instance暂定44位，标识域下不同服务实例。
二、协议栈API设计
2.1ServiceIP申请功能
申请ServiceIP流程如图3所示，该功能主要实现应用的ServiceIP的申请及下发。根据业务携带应用商店全局部署的ServiceName和可选Domain、SubServiceID字段进行ServiceIP的申请，控制器收到相应的申请后，根据是否携带Domain字段来决策扁平化或者全局化分配InstanceID，并且组装ServiceIP后下发到APP上，同时通知其他协议栈/转发面该ServiceIP值。VPP为转发面。网络中每个设备设有一个用户态协议栈，对接其他设备的用户态协议栈。
如图3所示，ServiceIP申请流程包括：APP1发出业务注册请求，请求中可包括servicename、Domain、SubServiceID等信息；对应的用户态协议栈上线，发起ServiceIP注册；控制器生成ServiceIP并下发给用户态协议栈(也向该用户态协议栈下发全局其他协议栈ServiceIP和策略路由表)，并向其他协议栈和转发面同步ServiceIP相关表项；APP1对应的用户态协议栈存储本地表项、生成全局表项，并进行表项对账，然后向对应的APP1返回请求结果，包括通知业务callback servip、策略控制等数据。
去申请流程与申请流程类似。该功能提供两个对外API接口：
函数名 功能 备注
App_Register() 注册APP的ServiceIP地址
App_UnRegister() 去注册APP的ServiceIP地址
2.2Service服务发布功能
在APP中存在服务端和客户端模式，针对服务端设计需要有资源的发布需求，该设计中以图4中URL资源发布为例说明，发布时可以指定本地的一些策略，如只针对某个目的ServiceIP的资源发布，其他ServiceIP无法访问，或者针对某个域的资源发布等；发布完成后控制器会生成源ServiceIP与URL的映射关系，同时生成相应的策略路由进行全局通告。
如图4所示，ServiceIP服务发布流程具体包括：APP发布URL，可以指定发布策略，如指定目的ServiceIP/ServiceID或指定Domain发布，也可以无指定发布；对应的用户态协议栈查找源ServiceIP表和目的ServiceIP表，向控制器发出ServiceIP服务发布请求，请求中包括本地策略路由、URL、协议栈ServiceIP等信息；由控制器生成URL与协议栈ServiceIP的映射关系，进一步生成策略路由，向对应的用户态协议栈返回发布成功消息和通告全局策略；控制器将ServiceIP变化、URL表变化通告其他协议栈或者转发面；APP对应的用户态协议栈进行本地策略路由与全局策略路由对账,然后向对应的APP返回请求结果，包括服务发布成功callback信息。
示例说明如下：
协议栈1：本地一个APP的编址为serviceip1。发送本地serviceip1本地定制的策略路由，比如为一个黑白名单，指定可以访问serviceip1的黑名单为serviceip2、serviceip3；该信息通告给控制器；
协议栈2：本地一个APP的编址为serviceip2；发送本地serviceip2本地定制的策略路由，比如为一个黑白名单，指定可以访问serviceip2的黑名单为serviceip1；该信息通告给控制器；
控制器整合后，得到表项如下：serviceip1---serviceip2双向禁止访问；
Serviceip1---serviceip3单向禁止访问，不允许serviceip3访问serviceip1，但是serviceip1可以访问serviceip3，因为serviceip3没有定制策略；除了黑白名单外，还可以制定路由策略、NAT策略等。
该功能提供两个对外API接口：App_Publish()；App_UnPulish()
Figure BDA0003241389200000081
2.3Service的连接功能及收发功能
应用的单向连接流程如图5所示，在服务端发布服务后，挂接一个回调在应用协议栈中，即进入等待连接的到来；应用客户端调用app_opt_connect函数，发起一个到目的URL的知名地址的连接，并在连接属性中设置应用对网络的SLA需求属性，协议栈收到该SLA需求后，将应用的连接需求发送至控制器进行算路，因为控制器掌握了所有的网络层资源，所以根据应用的SLA需求进行网络层资源计算和预留，计算完成后将网络层隧道下发至网络层转发面VPP，同时告知协议栈算路结果；另外其中的SLA需求属性可以是单向的，这样的话回程的网络算路就由服务端协议栈决定，也可以是双向的，协议栈告知控制器，控制器将整体双向网络层隧道下发至转发面。图5所示为单向连接隧道，完成了应用对网络的SLA需求表达、网络算路、协议栈的ServiceIP层封装发送、转发面的IP层网络隧道封装等过程。
如图5所示，Service的连接功能及收发流程具体包括：服务端APP-S发布服务后，挂接一个回调在应用协议栈中，即调用APP_recv_callback()函数，等待连接的到来；作为客户端的APP-C调用app_opt_connect函数，设置目的URL的SLA属性并发起连接；APP-C对应的用户态协议栈发起应用算路请求给控制器；控制器根据应用的SLA需求进行网络层资源计算，算好后将网络层隧道下发至网络层转发面，同时告知客户端的用户态协议栈算路结果，告知服务端APP-S对应的用户态协议栈回程源ServiceIP、SLA需求等信息，服务端的用户态协议栈发送建链通知给APP-S；APP-C调用App_SendBuf函数，发出URL的报文请求，由对应的用户态协议栈完成ServiceIP层封装，然后由转发面VPP进一步完成网络层隧道封装；封装后的报文经IP隧道网络传输，在到达服务端之前，由转发面解封装网络隧道，然后再经过服务端对应的用户态协议栈解封装ServiceIP层后传送给APP-S。
该功能提供如下对外API接口：
Figure BDA0003241389200000091
三、报文的收发
报文的收发框架如图6以APP1对APP3发起连接为例，转发面以VPP转发为例；整个报文封装流程如下：在协议栈上面完成策略查找，策略查找通过后，进行ServiceIP层封装，ServiceIP采用IPV6地址的格式，可以可选性添加扩展头即option头，里面可以携带端到端应用的私有化信息；在转发面VPP上完成网络隧道的封装，协议栈与VPP的交互通过共享内存接口memif进行通信，在交互消息头中，携带了应用的信息，为VPP基于ServiceIP进行查找网络隧道提供封装依据。
四、移动性机制
域内移动：对于终端如果域内移动，则ServiceIP不变。需要重新注册上线，接入的本地协议栈刷新本地ServiceIP表项；离开的协议栈保活删除本地ServiceIP表项。控制器对于重新注册上线的ServiceIP，发现是同一个ServiceIP表项，但是位置发现变更，需要将新表项向原注册协议栈设备发起刷新，对VPP需要发起ServiceIP与网络隧道的重新绑定。整个过程应用层用户APP不感知。
域间移动：对于终端如果域间移动，则ServiceIP可能发生变化。需要重新注册上线，注册后，控制器发现域发生了位置变化，对于层次化ServiceIP会重新生成ServiceIP，该ServiceIP只修改Domain字段，对全局刷新相应的ServiceIP表项。域间移动后，本地ServiceIP表保活后删除。对于扁平化部署整个过程应用层用户APP不感知，但是如果APP用户选择了层次化部署，需要修改ServiceIP的Domain字段，协议栈和APP依然可以依据相应的编址格式发现是同一个APP。
五、基于应用的策略控制
1、服务发布的本地策略：
基于ServiceIP层次化分级，可以由服务源端发布服务时，指定相应的标识策略，在服务发布一章中，基于之前的标识编码规则，可以指定ServiceID、Domain、ServiceIP等不同策略，如果指定ServiceID，则该发布的服务会对该ServiceID下的所有ServiceIP提供或者禁止提供服务；指定ServiceIP，则该发布的服务精确对该ServiceIP提供禁止或者专项服务。
2、控制器指定的全局策略
1)黑白名单
在协议栈指定服务资源访问的黑白名单，其表项如下所示；协议栈基于该黑白名单在应用层即可以禁止或者运行APP网络资源的访问，从而净化网络资源，保证网络带宽的合理使用。
服务URL 源端ServiceIP 目的ServiceIP 目的ServiceIP Action
www.123.com 0xFD11**** 无 0xFD12**** permit
www.123.com 0xFD13**** deny
2)路由策略
指定配置基于Domain、ServiceID、ServiceIP三个字段的策略方式；该策略中可以配置全局的路由命令，第一条命令标识协议栈对目的之地是domain1的访问是拒绝的；第二条命令标识协议栈对源serviceip2，目的serviceip1的访问是允许的。
形如：
routepolicy dest domain 1action deny
routepolicy dest serviceip1 src serviceip2 action permit
3)NAT策略
对于非全局ServiceIP管理，需要在协议栈上执行类型NAT的操作，将ServiceIP替换成知名的ServiceIP然后转发。
本发明提出的用户态协议栈的API接口的设计理念，针对多APP接入场景下，通过控制器分配的ServiceIP层进行应用APP通信；该API接口涉及网络感知应用的SLA需求、CS模式的服务发布、策略控制、报文收发等功能API接口。此外，本发明提出的一种基于应用的用户态协议栈的设计接口，解决了应用移动性问题。使得应用基于ServiceIP的方式，不会随着网络地址的变化而变化，从而保证了应用的寻址和定位的分离。而且，本发明还提出了一种基于应用的编址思路和具体实现方式，在编址中，提出了编址的格式，提出了扁平化和层次化编址的思想。综上，本发明技术方案能够带来如下有益效果：
(1)提供了一套基于用户APP的API接口：该接口是目前基于应用的API接口的首次尝试，该接口中例如基于应用的连接请求中，应用可以指定对网络的SLA需求，传递至协议栈后，协议栈基于该应用的SLA请求，向控制器申请匹配SLA的网络隧道，控制器可以汇总APP的SLA需求，从全局角度优化网络资源；基于应用的服务发布请求，可以指定网络隧道；基于应用的收发包请求完成网络数据包的封装及分发。
(2)基于协议栈的设计，进行APP的策略控制：传统设计中APP接入、传输是无法控制的。本发明中因为用户态APP协议栈的引入，使得APP可以在协议栈中基于ServiceIP进行相应的策略控制。目前策略控制包括服务发布本地化策略控制，控制器网关下发的黑白名单控制，ServiceIP路由的层次化策略控制、NAT策略控制等。通过策略控制，可以完成传统网络所不具备的完成应用的优化表项传输，应用端到端控制等功能。
(3)解决网络移动性问题：传统网络中基于IP+端口的思路无法解决移动性问题，在APP频繁移动中必然伴随着网络的震荡。本发明基于ServiceIP进行应用层编址和API控制，在应用移动后，控制器感知后，网络层刷新ServiceIP层和网络层的映射表即可。
本发明中部分涉及到的字符表示的含义如下：
ULA：unique local addresses，唯一区域地址。
API：Application Program Interface，应用程序接口。
APP：Application，应用程序。
URL：Uniform Resource Locator，统一资源定位符。
SLA：Service-Level Agreement，服务等级协议。
SDN：Software Defined Network，软件定义网络。
HIP：Host Identity Protocol，HIP协议。
Domain：域。
NAT：Network Address Translation，网络地址转换。
以上所述仅是本发明的优选实施方式，应当指出：对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (11)

1.一种基于应用和用户态协议栈的网络管理方法，其特征在于：所述方法应用于网络架构，网络架构包括应用层、TCP层、网络层和控制器，TCP层和应用层之间设有ServiceIP层，应用层包括多个APP，在所述ServiceIP层部署至少一个用户态协议栈，用户态协议栈为一个以上的APP所使用；
所述方法包括步骤：
S1.控制器接收来自任一APP发出的APP请求，APP请求通过对应的用户态协议栈发送给控制器；
S2.控制器对APP请求进行处理，并将处理结果反馈给对应的用户态协议栈，由对应的用户态协议栈将控制器的处理结果发送给对应的APP。
2.如权利要求1所述的基于应用和用户态协议栈的网络管理方法，其特征在于，在所述APP请求为业务注册请求时，所述步骤S2具体为：
控制器通过用户态协议栈接收APP发送的包含ServiceName、Domain、SubServiceID字段的ServiceIP注册请求，根据请求信息组装ServiceIP，经用户态协议栈下发到APP上；
控制器将得到的ServiceIP发送给其他用户态协议栈或转发面。
3.如权利要求1所述的基于应用和用户态协议栈的网络管理方法，其特征在于，在所述APP请求为服务发布请求时，所述步骤S2具体为：
发出服务发布请求的APP作为服务端，通过对应的用户态协议栈向控制器发送服务发布请求，服务发布请求包括本地策略路由和协议栈ServiceIP表，本地策略路由包括指定发布策略，在指定发布策略中指定访问的黑白名单、访问策略；
控制器整合接收到的全局内所有服务发布请求，生成相应的全局策略路由，然后向对应的用户态协议栈返回发布成功消息，通告全局策略路由；
控制器将ServiceIP和策略路由通知其他协议栈或转发面。
4.如权利要求3所述的基于应用和用户态协议栈的网络管理方法，其特征在于：所述服务发布请求为URL资源发布请求，APP通过对应的用户态协议栈向控制器发出服务发布请求中还包括URL，控制器生成的全局策略路由中包括URL与协议栈ServiceIP表的映射关系，URL变化由控制器通知到其他用户态协议栈或转发面。
5.如权利要求3所述的基于应用和用户态协议栈的网络管理方法，其特征在于，在所述APP请求为连接或收发请求时，所述步骤S2具体为：
发出连接或收发请求的APP作为客户端；连接或收发请求中指定应用对网络的SLA需求，SLA需求用于标识App服务等级；作为客户端的APP发起一个到目的URL的知名地址的连接，并在连接属性中设置对网络的SLA需求；
对应的用户态协议栈将APP的连接需求发送至控制器进行算路；
控制器整合所有SLA需求，从全局角度进行网络层资源计算和优化，计算网络隧道并下发至网络层转发面，并告知对应的用户态协议栈算路结果；
客户端由用户态协议栈发送URL的报文请求，由用户态协议栈完成ServiceIP层封装之后，发送给转发面进行网络隧道封装；
经过封装的报文请求在到达服务端前，由转发面解封装网络隧道、由服务端的用户态协议栈解封装ServiceIP层，然后到达服务端的APP。
6.如权利要求1所述的基于应用和用户态协议栈的网络管理方法，其特征在于，在所述APP请求为报文收发请求时，所述步骤S2具体为：
源APP在对应的用户态协议栈上面完成策略查找，策略查找通过后，对报文收发请求进行ServiceIP层封装；在转发面上基于ServiceIP查找对应的源网络隧道和目的网络隧道，完成网络隧道的封装；
经过封装的报文请求在到达目的APP前，由转发面解封装网络隧道、由目的APP的用户态协议栈解封装ServiceIP层，然后到达目的APP。
7.如权利要求6所述的基于应用和用户态协议栈的网络管理方法，其特征在于，所述ServiceIP采用IPV6地址的格式，选择性添加扩展头，扩展头中携带APP的源端到目的端的私有化信息。
8.如权利要求1-7任一所述的基于应用和用户态协议栈的网络管理方法，其特征在于：所述SerivceIP包括0xfd、ServiceType、ServiceID、SubServiceID和InstanceID五种字段，其中，
0xfd用于标识一个ULA地址；
ServiceType用于标识ServiceAPP的类型；
ServiceID由控制器全局分配，用于标识相同ServiceType下的Service的ID，一个Service对应全局惟一的一个ServiceID；
SubServiceID用于标识相同ServiceID下的不同子服务的ID；
InstanceID用于标识不同服务实例；控制器根据ServiceIP申请请求中是否携带Domain字段来决策扁平化或者全局化分配InstanceID。
9.一种网络架构，包括应用层、TCP层、网络层和控制器，应用层包括多个APP，其特征在于：
所述应用层和TCP层之间设有ServiceIP层，用于为APP进行ServiceIP编址；
所述ServiceIP层部署一个以上的用户态协议栈，用户态协议栈为一个以上的APP所使用，用户态协议栈中存有本地ServiceIP表项和全局ServiceIP表项；
所述控制器用于接收任一APP发出的APP请求，APP请求通过对应的用户态协议栈发送给控制器；
控制器对APP请求进行处理，并将处理结果反馈给对应的用户态协议栈，由对应的用户态协议栈将控制器的处理结果发送给对应的APP；
ServiceIP层用于接收APP发出的业务注册或者去注册请求，向控制器申请为对应的APP注册对应的ServiceIP或者注销ServiceIP。
10.根据权利要求9所述的一种网络架构，其特征在于：所述APP和用户态协议栈之间定义用于数据传递的对外API接口，对外API接口包括注册APP的ServiceIP地址的API接口、注销APP的ServiceIP地址的API接口、服务发布的API接口、取消服务发布的API接口、感知APP请求的API接口、屏蔽APP请求的API接口、发送报文的API接口、接收报文的API接口。
11.根据权利要求9所述的一种网络架构，其特征在于：所述SerivceIP包括0xfd、ServiceType、ServiceID、SubServiceID和InstanceID五种字段，其中，
0xfd用于标识一个ULA地址；
ServiceType用于标识ServiceAPP的类型；
ServiceID由控制器全局分配，用于标识相同ServiceType下的Service的ID，一个Service对应全局惟一的一个ServiceID；
SubServiceID用于标识相同ServiceID下的不同子服务的ID；
InstanceID用于标识不同服务实例；控制器根据ServiceIP申请请求中是否携带Domain字段来决策扁平化或者全局化分配InstanceID。
CN202111019683.1A 2021-09-01 2021-09-01 基于应用和用户态协议栈的网络管理方法及网络架构 Active CN113726577B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111019683.1A CN113726577B (zh) 2021-09-01 2021-09-01 基于应用和用户态协议栈的网络管理方法及网络架构

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111019683.1A CN113726577B (zh) 2021-09-01 2021-09-01 基于应用和用户态协议栈的网络管理方法及网络架构

Publications (2)

Publication Number Publication Date
CN113726577A true CN113726577A (zh) 2021-11-30
CN113726577B CN113726577B (zh) 2023-10-24

Family

ID=78680426

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111019683.1A Active CN113726577B (zh) 2021-09-01 2021-09-01 基于应用和用户态协议栈的网络管理方法及网络架构

Country Status (1)

Country Link
CN (1) CN113726577B (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106302199A (zh) * 2016-08-10 2017-01-04 成都广达新网科技股份有限公司 一种基于三层交换机设备的用户态协议栈实现方法及***
CN110493329A (zh) * 2019-08-08 2019-11-22 西藏宁算科技集团有限公司 一种基于用户态协议栈的并发推送服务方法和***
CN112422453A (zh) * 2020-12-09 2021-02-26 新华三信息技术有限公司 一种报文处理的方法、装置、介质及设备
CN112506674A (zh) * 2019-09-16 2021-03-16 北京华耀科技有限公司 Linux***下用户态TCP/IP协议栈与本地应用通信的***及方法
CN112637329A (zh) * 2020-12-21 2021-04-09 网络通信与安全紫金山实验室 一种多应用程序的标识方法、装置、设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106302199A (zh) * 2016-08-10 2017-01-04 成都广达新网科技股份有限公司 一种基于三层交换机设备的用户态协议栈实现方法及***
CN110493329A (zh) * 2019-08-08 2019-11-22 西藏宁算科技集团有限公司 一种基于用户态协议栈的并发推送服务方法和***
CN112506674A (zh) * 2019-09-16 2021-03-16 北京华耀科技有限公司 Linux***下用户态TCP/IP协议栈与本地应用通信的***及方法
CN112422453A (zh) * 2020-12-09 2021-02-26 新华三信息技术有限公司 一种报文处理的方法、装置、介质及设备
CN112637329A (zh) * 2020-12-21 2021-04-09 网络通信与安全紫金山实验室 一种多应用程序的标识方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN113726577B (zh) 2023-10-24

Similar Documents

Publication Publication Date Title
CN112470436B (zh) 用于提供多云连通性的***、方法、以及计算机可读介质
CN111193653B (zh) 数据传输方法、装置、设备及存储介质
WO2022121349A1 (zh) 算力应用流量转发方法及装置
CN105264493B (zh) 信息中心网络上的动态虚拟机迁移
US9252963B2 (en) Performing multicast communication in computer networks by using overlay routing
CN103581299B (zh) 服务调度方法、装置及***
EP2381647B1 (en) Session migration in content-centric networks
US20200059976A1 (en) IoT DEVICE CONNECTIVITY, DISCOVERY, AND NETWORKING
WO2023000935A1 (zh) 一种数据处理方法、网元设备以及可读存储介质
US20160094650A1 (en) Non-overlay resource access in datacenters using overlay networks
EP2687982A1 (en) Hierarchical system for managing a plurality of virtual machines, method and computer program
US10904342B2 (en) Container networking using communication tunnels
US20180288726A1 (en) Active Position Driven Mobility Content Delivery in Information Centric Networks
WO2015108106A1 (ja) パケット転送装置、制御装置、通信システム、通信方法及びプログラム
CN113556413B (zh) 一种报文处理方法及装置
KR20120038187A (ko) 컨텐츠 중심 네트워킹 환경에서 그룹 변경에 관한 정보를 이용한 컨텐츠 공유 방법 및 장치
CN110089078A (zh) 提供经由动态覆盖网络的业务转发器的方法和设备
CN106209996A (zh) 通信处理方法和装置
CN101355492A (zh) 简单对象访问协议路由方法及路由***以及相关设备
US9882872B2 (en) Method and apparatus for inter-domain routing based on as architecture
EP1959637A1 (en) Method and apparatus for session aware connectivity control
US20120300776A1 (en) Method for creating virtual link, communication network element, and ethernet network system
US11337038B2 (en) Method, device and system for transmitting multicast group information
CN113726577A (zh) 基于应用和用户态协议栈的网络管理方法及网络架构
CN106165344A (zh) 在被耦合到软件定义的交换机的网关中分配虚拟机

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant