CN107852335A - 软件定义网络中的服务或设备发现消息的重定向 - Google Patents
软件定义网络中的服务或设备发现消息的重定向 Download PDFInfo
- Publication number
- CN107852335A CN107852335A CN201580081546.7A CN201580081546A CN107852335A CN 107852335 A CN107852335 A CN 107852335A CN 201580081546 A CN201580081546 A CN 201580081546A CN 107852335 A CN107852335 A CN 107852335A
- Authority
- CN
- China
- Prior art keywords
- service
- network
- server
- message
- messages
- 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.)
- Pending
Links
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/12—Discovery or management of network topologies
- H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1854—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with non-centralised forwarding system, e.g. chaincast
-
- 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/5058—Service discovery by the service manager
-
- 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/02—Topology update or discovery
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
提供了一种用于在软件定义网络(SDN)中重定向服务或设备发现(SD)消息的方法。该SDN包括多个网络节点,一个或多个SD服务节点和服务器。通过所述服务器指示所述多个网络节点中的一个或多个网络节点,以将接收的广播或多播SD消息作为单播或多播SD消息重定向到一个或多个选择的SD服务节点。
Description
技术领域
本发明涉及软件定义网络(Software-Defined Networks,SDN)中的服务或设备发现消息。
背景技术
服务和设备发现(Service And Device Discovery,SD)程序用于自动和动态检测计算机网络内的服务和设备。通常,SD程序使用特定的发现协议来通知或检测可用的服务和设备。当发现协议未意识到网络中存在任何特定实体时,其最初可以通过向网络发送广播或多播SD消息来开始。然而,广播或多播SD消息,由于会引起与SD有关的广播泛洪,可能对计算机网络造成不利影响。
例如,当使用以太网和TCP/IP时,多播消息可能导致L2(第2层)广播消息,由于不存在具有包裹IP数据包的以太网帧所指向的多播MAC地址的收件人,并且因为L2广播消息需要被传递到每个网络端口,因此可能需要相当多的网络资源。对于给定的网络,这只能扩展到某些数量的设备和网络端口,并且可能需要限制L2分片的大小。此外,虽然路由器或网关可以用于互连分离L2分片,但是它们可能被要求不在分片边界上中继广播消息,从而使得在L2分片边界上发现其他有用的服务和设备变得复杂。
发明内容
根据本发明的第一方面,提供了一种在软件定义网络SDN中重定向服务或设备发现(SD)消息的方法,该SDN包括多个网络节点、一个或多个SD服务节点和服务器。该方法包括:所述服务器指示所述多个网络节点中的一个或多个网络节点,将接收的广播或多播SD消息作为单播或多播SD消息重定向到一个或多个选择的SD服务节点。本申请中的“重定向”包括将消息的目的地址改变,以及将所述消息转发到新的目的地。
因此,通过将广播或多播SD消息重定向到(专用)SD服务节点来避免SD相关的广播泛洪。在这方面,在整个说明书和权利要求书中使用的术语“服务或设备发现消息”应被广义地理解,并且覆盖含有与服务或设备的通知相关的信息的任何消息以及含有涉及搜索服务或设备的信息的任何消息。此外,在整个说明书和权利要求书中使用的术语“软件定义网络”应被广义地理解,并且覆盖具有一个或多个网络节点的任何网络,所述网络节点存储消息转发规则并且用于允许通过向网络连接上的网络节点发布控制消息来重新编码或更新消息转发规则。
此外,在整个说明书和权利要求书中使用的术语“SD服务节点”应被广义地理解,并且覆盖存储SD相关信息(诸如关于提供服务、设备的存在、或其他网络节点搜索服务或设备的信息)的网络节点。具体来说,术语SD服务节点包括将存储的信息提供给需要所述信息的网络节点的网络节点。此外,虽然广播和多播SD消息可以作为多播SD消息被重定向到网络中的所有SD服务节点,但是也可以考虑将接收到的广播或多播消息重定向到可用的SD服务节点中的一些或仅一个,例如基于不同的SD消息类型分配给一个或多个可用SD服务节点。
此外,多播消息(除广播消息之外)的重定向在依赖于在链路层和上层的TCP/IP簇的以太网家族(所有版本的以太网,交换以太网,WiFi)的网络技术的计算机网络上都是特别有利的。这是因为使用以太网和TCP/IP,多播消息通常会导致需要传送到每个网络端口的L2广播消息。实际上,这只能扩展到低数量的设备和网络端口,并且可能需要限制L2分片的大小。然而,可能要求IP路由器(或IP网关)互连分离的L2分片不会通过IP子网边界中继广播消息,否则使得IP子网边界上有用的设备和服务的发现变得复杂。
在第一方面的第一实施方式中,服务器指示一个或多个网络节点中的每一个以一组重定向规则来更新其流表,每个流表定义要被应用于到达相应网络节点的消息的转发规则。
因此,重定向不需要是静态的,如果需要或想要的话,可以进行更新。例如,当将新的SD服务节点插入到网络中时,可以更新重定向规则以将SD消息,尤其是特定服务类型的SD消息重定向到新的SD服务节点。此外,可以从重定向规则中删除与网络断开的SD服务节点,使得先前重定向到所述SD服务节点的消息可以被重定向到另一SD服务节点。
根据第一方面或第一方面的第一实施方式,在第一方面的第二实施方式中,所述方法还包括所述服务器通过分析所述SDN的网络拓扑确定所述一个或多个网络节点;以及所述服务器选择所述一个或多个网络节点中的至少一个,其中每个所选择的网络节点形成所述SDN的端点,从而将接收的广播或多播SD消息作为单播或多播SD消息重定向到所述一个或多个所选择的SD服务节点。
如在整个说明书和权利要求书中所使用的,术语“SDN的端点”要被理解为根据网络拓扑可以连接到可以提供或请求服务的新的计算设备或连接到另一个网络的网络节点,例如网络边缘的网络节点、交换机或路由器,的网络节点。此外,端点可以是具有至少一个暴露于不同SDN网络中的非SDN控制交换机或SDN控制交换机的接口的SDN控制交换机。特别地,SDN的端点可以是具有可以连接到以太网电缆可连接的墙上插座中的插头的有线连接的交换机。
根据第一方面或第一方面的第一或第二实施方式,在第一方面的第三实施方式中,所述方法还包括:所述一个或多个所选择的SD服务节点中的一个SD服务节点接收重定向的SD消息;基于所接收的SD消息的服务类型,所述一个SD服务节点确定提供或请求所述服务类型的服务的计算设备。该方法还包括所述一个SD服务节点向所述SD消息的发送者发送对所述SD消息的单播响应,所述响应指示所确定的计算设备;或者所述SD服务节点将所述SD消息转发到所确定的计算设备,所述计算设备之后直接回复所述SD消息的发送者。该方法还包括所述一个SD服务节点存储将提供服务和请求服务链接到计算设备的查询表,其中,所述查询表由所述一个SD服务节点基于所接收的SD消息进行更新。
因此,SD服务节点提供请求设备,SD消息来自于该请求设备,具有关于提供(或请求)所需服务的设备的信息,或将SD消息转发到提供(或请求)所需服务的设备。因此,该请求设备可以通过向网络发送广播或多播SD消息来了解提供或请求特定服务的其他设备,而不会泛洪网络。
根据第一方面的第一至第三实施方式中的任一的或根据第一方面,在第一方面的第四实施方式中,服务器包括一个或多个SD服务节点。
因此,服务器可以指示一个或多个网络节点将SD消息重定向到其自身。服务器然后可以直接响应SD消息,或者将所接收的SD消息转发(或分发)给提供或请求如SD消息中指示的特定服务的计算设备,从而减少SD过程中涉及的专用硬件单元的数量。
在第一方面的第五实施方式中,根据第一方面的第一至第三实施方式中的任一或根据第一方面的方法应用于网络,该网络包括所述SDN和连接到所述SDN的端点的多个计算设备并且运行服务或设备发现协议,其中所述服务或设备发现协议的类型是通用即插即用(Universal Plug and Play,UPNP),简单服务发现协议(Simple Service DiscoveryProtocol,SSDP),零配(zero configuration,zeroconf),会话描述协议(SessionDescription Protocol,SDP),Bonjour(苹果(Apple)公司推出的零配置网络协议)或数字生活网络联盟(Digital Living Network Alliance,DLNA)之一。
因此,可以重定向相同服务或设备发现协议的SD消息,同时保留服务或设备发现协议的功能并避免SD消息网络泛洪。
根据本发明的第二方面,提供了一种在软件定义网络SDN中使用的服务器,所述服务器维护一个或多个网络节点的消息转发规则的集中视图,并且用于指示所述一个或多个网络节点以更新其流表,每个流表定义要被应用于到达相应网络节点的消息的转发规则,以使得所述一个或多个网络节点将接收的广播或多播SD消息作为单播或多播SD消息重定向到一个或多个所选择的SD服务节点。
因此,服务器——可以是例如包括一个或多个开放流(OpenFlow,OF)交换机的网络的OF控制器——可以控制一个或多个OF交换机来更新其流表以将SD消息重定向到一个或多个所选择的SD服务节点,以避免SD消息泛洪网络。
在第二方面的第一实施方式中,服务器用于分析SDN的拓扑,通过分析所述SDN(20)的拓扑来确定一个或多个网络节点,并且用于选择形成SDN的端点的至少一个网络节点,以将接收的广播或多播SD消息作为单播或多播SD消息重定向到一个或多个所选择的SD服务节点。
因此,服务器监视可以连接计算设备的那些网络节点(交换机),并指示所述网络节点将接收到的广播或多播SD消息重定向到一个或多个所选择的SD服务节点,从而防止广播或多播SD消息在第一跳泛洪网络。
根据第二方面的第一实施方式或第二方面本身,在第二方面的第二实施方式中,服务器用于指示所述一个或多个网络节点,以在学习激活SDN中新的SD簇时安装新的转发规则。
特别地,新的转发规则可以针对重定向新SD簇的服务或设备发现或通知消息以允许支持新的SD簇。
根据本发明的第三方面,提供了一种在软件定义网络SDN中使用的服务或设备发现SD服务节点,所述SD服务节点用于接收SD消息,基于所接收的SD消息的服务类型确定提供或请求所述服务类型的服务的计算设备。SD服务节点还用于向如所述SD消息中指示的所述SD消息的发送者发送对所述SD消息的单播响应,所述单播响应指示所确定的计算设备和/或将所述SD消息转发到所确定的计算设备。SD服务节点还用于存储将提供服务和请求服务链接到计算设备的查询表,并基于接收的SD消息来更新所述查询表。
因此,SD服务节点通过向消息的始发者提供关于另一计算设备的服务提供能力或服务需求的所需信息来响应所接收的SD消息,或者将SD消息转发到满足由SD消息的服务类型指定的服务请求或提供的设备。在这方面,术语“服务类型”应在广义上被理解,并且覆盖专用的单一服务以及服务组,或者甚至是关于网络中的任何哪种服务可用的一般查询。
在第三方面的第一实施方式中,SD服务节点还用于使一个或多个网络节点将所述一个或多个网络节点接收的广播或多播SD消息作为单播SD消息重定向到SD服务节点。
因此,在该实施方式中,SD服务节点充当上述服务器。特别地,SD服务节点和服务器的功能可以以在特定硬件单元或IP主机上运行的软件来实现,在该情况下,所述硬件单元可能(取决于环境)充当SD服务节点或上述可以例如提供OF网络控制器功能的服务器。
根据本发明的第四方面,提供了一种用于在软件定义的网络SDN中使用的网络节点,所述网络节点用于接收将接收的广播或多播SD消息作为单播或多播SD消息重定向到一个或多个选择的SD服务节点的指令。
因此,可以是例如OF交换机的网络节点通过减少接收者的数量来避免网络的SD消息泛洪,其中原始SD消息——其为广播或多播消息——被转换(就减少预期收件人而言)为发往一个或多个选择的SD服务节点的另一个消息。
在第四方面的第一实施方式中,网络节点用于接收利用一组重定向规则来更新其流表的指令,以响应从服务器接收的控制消息,其中所述流表定义要被应用于到达所述网络节点的消息的转发规则。
因此,网络节点可以被即时地重新配置成,例如,集成新的SD服务节点或删除SD服务节点。减少了维护工作,并提供了SD过程在现有网络中的无缝集成。
根据第四方面的第一实施形式,在第四方面的第二实施方式中,网络节点用于分析接收的SD消息并且选择一个或多个SD服务节点,基于分析结果和重定向规则的设定进行重定向。
因此,与不同类型的服务相关的SD消息可以针对专用的SD服务节点,以便于服务请求和服务提供(通知)的匹配。此外,与高优先级业务相关的SD消息可以被冗余地发送到几个SD服务节点,以提高SD服务节点故障的情况下的可用性。
根据第四方面本身或根据第四方面的第一或第二实施方式,在第四方面的第三实施方式中,所接收的广播或多播SD消息符合UPNP,SSDP,zeroconf,SDP,Bonjour或DLNA的服务或设备发现协议。
因此,SD过程与当前的SD协议或簇兼容,并因此可以与当前的计算设备无缝集成。
根据本发明的第五方面,提供一种网络,所述网络包括包含根据第二方面或第二方面的第一实施方式的服务器,和/或根据第三方面或第一方面的第一实施方式的一个或多个SD服务节点,和根据第四方面或第四方面的第一至第三实施方式中的任何一个的多个网络节点的软件定义网络SDN;以及至少两个计算设备,被连接到所述SDN的端点并且运行服务或设备发现协议,其中所述服务或设备发现协议的类型是UPNP,SSDP,zeroconf,SDP,Bonjour或DLNA之一。
附图说明
现在将参照附图仅通过示例方式来描述本发明的几个示例,其中:
图1是根据本发明的网络的实施例的图示;
图2示出了具有独立SD服务节点的网络中UPnP SD簇的激活;
图3示出了在具有独立SD服务节点的网络中通知新服务或设备的UPnP SSDP消息的示例性重定向过程;
图4示出了在具有独立SD服务节点的网络中针对搜索服务的UPnP SSDP消息的示例性重定向过程;
图5示出了在服务器包括SD服务节点的网络中UPnP SD簇的激活;
图6示出了在服务器包括SD服务节点的网络中通知新服务或设备的UPnP SSDP消息的示例性重定向过程;以及
图7示出了在服务器包括SD服务节点的网络中针对搜索服务的UPnP SSDP消息的示例性重定向过程。
具体实施方式
图1示出了包括连接到第一网络节点(或交换机)14的第一计算设备12和连接到第二网络节点(或交换机)18的第二计算设备16的网络10。第一网络节点(交换机)14和第二网络节点(交换机)形成作为网络10的一部分的软件定义网络(SDN)20的端点。SDN 20还包括连接到第一网络节点(交换机)14和第二网络节点(交换机)18的第一SD服务节点(或SD服务器)22和第二SD服务节点(或SD服务器)24。此外,SDN 20还包括网络节点(交换机)26、28和服务器30。
网络节点(交换机)14、18、26、28的控制平面集中在服务器30中,从而与SDN 20的数据平面分离。数据平面业务与控制平面业务之间的差异在于通信目的的语义。数据平面业务可以是——例如从第一计算设备12到第二计算设备16的——正常的终端用户载荷的交换,而控制平面业务涉及由某些所有者(运营商,网络管理员,等等)通过作为控制平面中的网络节点(交换机)14、18、26、28的SDN控制器的服务器30执行的控制。
例如,服务器30可以通过其“南向API”(SBI)与网络节点(交换机)14、18、26以及28进行通信,以维持SDN 20的状态的集中视图。具体地说,南向的API可以由开放流(OpenFlow,OF)协议实现,使得服务器30能够充当OF控制器。通过其“北向API”(NBI),服务器30可以启用能够在服务器30上运行的控制应用程序来操纵SDN 20的状态并执行应用程序的逻辑。
服务器30可以通过其南向的API来指示网络节点(交换机)14、18、26、28将接收的诸如广播或多播SD消息等的消息(流)作为单播或多播SD消息重定向到SD服务节点22和24。在这方面,流基本上可以被描述为共享L2-L3-L4协议位的公共集合(例如,“发送到相同IP地址的所有数据包”)的数据包的序列。到目前为止,服务器30可以通过其南向的API来指示网络节点(交换机)14、18、26、28中的每一个,以一组重定向规则来更新它们的流表。
网络节点(交换机)14、18、26或2814、18、26或28的流表可以是与网络节点(交换机)14、18、26以及28中的相应的一个相关的所有流处理规则的集合。这种重定向规则可以根据识别哪种SD消息以及当SD消息到达网络节点(交换机)14、18、26或28之一时应用什么动作来描述准则14、18、26或28。基于流表,网络节点(交换机)14、18、26以及28可以将所有L2广播,多播或任何其他类型的服务或设备发现簇使用的搜索和通知消息(即,用于网络上的服务和/或设备的通知和发现)重定向到SD服务节点22和24。
服务器30或另一个网络设备可以实现服务注册服务组件(Service RegistryService Component,SRSC)来控制或利用服务器30在所有相应的网络节点(交换机)14、18、26以及28中(例如,在所有交换机中或仅在“边缘”交换机中)部署SD簇特定的转发规则。SRSC可以具有相应的SD格式的知识,并且可以控制或与服务器30接口以根据需要部署对应的OF转发规则。这些规则可能被制定成正确匹配涉及的不同SD协议,并且所包括的动作可以定义如何处理匹配流。在这方面,可以考虑动作的以下示例性的而非限制性的策略:
●将特定流重定向到服务器30,服务器30可以随后将其分别分配到在服务器30上(例如通过软件)实现的负责的SDN SD控制应用(SDN SD Control Application,SSCA);
●将特定流重定向到相应的服务节点22和/或24;或者
●阻止特定流,由于其不符合本地策略,例如来自未授权的用于服务通知的端口或未授权的特定的SD簇使用的端口,或在特定时间未授权的特定的SD搜索或通知等。
SSCA和SD服务节点22和24两者都可以分别实现支持SD簇的集中化。因此,所有与SD相关的流(公告,通知和搜索)可以由于受服务器30指示被网络节点(交换机)14、18、26以及28重定向到服务节点22和24。利用这样的信息,服务器30可以维护更新网络10中各自可用的服务及其位置的数据库。使用本地SD策略,SD服务节点22和24可以分别将传入的搜索请求匹配到可用的最适合的服务端点,例如,分别匹配到计算设备12和16。例如,根据一示例,可以通过SD服务应答节点22或24对来自可能位于二楼(由于可以根据计算设备12的网络连接点确定)的第一计算设备12的对打印机的搜索请求,以相同层上的打印机信息进行应答,即使在该同一建筑物内可能有几台打印机可用。
在这方面,应当注意,上述实施例不限于上述不再相互排斥的策略,因此可以使用混合策略,采用按照端口,主机,时间,SD类型等的几个不同的策略。因此,重定向的目标可以是整个SDN网络20中的一个单个中心元件(例如,在服务器30或SD服务节点22和24中的一个上实现的SSCA)。此外,可以使用不同的元素(零到几个SSCA,零到几个SD服务节点22和24或其混合),以分配SD业务/计算负载,而分配可以是按照SD协议(例如,用于UPnP的SSCA和用于DNS-SD的SD服务节点22)进行,或通过服务类型,例如,打印SD应用和多媒体SD应用等进行。此外,SSCA实例可以通过将接收到的SD消息从服务器30重定向到SD服务节点22和/或24来进一步发送消息。此外,所有这些实体都是功能性的,并且在给定的实施方案中,SRSC,SSCA和SD服务节点22和24可以(但不必)驻留在一个单一的IP主机,例如服务器30中。
SRSC可以使用服务器30的NBI向服务器30注册新的SD类型,例如DHCP,UPNP,SSDP,zeroconf,SDP,Bonjour或DLNA。该注册可以描述各个SD格式的不可改变的特征,以便定义匹配域。可以使用网络拓扑,以确定用于重定向的网络节点(交换机)14、18、26以及28。最后,还可以根据所使用的本地策略和可用的SD端点(例如服务器30上的SSCA或SD服务节点22和24),定义重定向目标。注册可以触发服务器30在所有具有可能接收SD相关的服务或设备发现请求或通知的端口的网络节点(交换机)14、18、26以及28中分发所描述的规则。
在这些注册之后,每个支持SD类型的所有(广播或多播)数据包可以由第一遇到的网络节点(交换机)14、18、26或28捕获,例如,在第一跳上并且通过控制平面被作为多播或单播消息重定向到定义的目标,其中目标可以是服务器30上或SD服务节点22和24中的一个或两个上的SSCA。如此指定的目标可以随后接收进入的流并且遵循由相应的SD簇标准定义的相应的SD过程的通常的后续步骤对所接收到的数据包进行处理,例如UPnP,zeroconf等。由于后续步骤可以依赖于至SD服务节点22和24的多播或单播业务,并且由于广播业务被捕获并且在控制平面上作为单播或多播被发送,和遇到第一网络节点(交换机)14或18一样早,在网络10被SD消息泛洪之前,所有广播或多播SD消息可以从网络10移除。
在这方面,需要注意的是,该过程并不限制SD范围。特别地,可以在整个网络10内通过搜索计算设备12和16来高效地找到服务,即使它们位于网络10的不同IP子网中、位于网络10的不同端上等等。实际上,相应的SD端点(指定为动作域内的目标,即SD服务器或服务器30上的SSCA)可以从整个网络10接收所有所定义的SD类型的SD请求。因此,该实体可以建立整个网络10内所有可用服务的中央注册表(来自服务通知),即跨越L2分片,IP子网边界等。以相同的方式,该相同的实体可以从所有感兴趣方接收服务或设备发现请求,而不管其在子网、字段等内的位置如何。该中心位置,可以通过为任何搜索请求找到最合适/可用的服务候选,来有效地解析整个网络10的所有服务或设备发现请求。
此外,当将搜索服务(例如,打印机)的感兴趣方(例如,客户端笔记本电脑)与可用的相应服务端点(即,第二层的彩色激光打印机)匹配时,在动作内定义的SD端点可以应用不同的策略。作为示例,SD端点(即,服务器30或SD服务节点22、24)可以找到最接近(拓扑或地理上)或语义上最好的(例如,重定向Mac OSX客户端到支持的打印机,Windows客户端到更合适的打印机)给定客户端的服务候选。作为另一个例子,SD端点可以通过在可用候选者中循环请求来进行负载平衡,还可以将客户端源地址与用户名相匹配,并例如通过隐藏来自特定客户端的特定服务来进行应用授权。
通过这种机制支持的典型策略可以是但不限于以下:
●移动策略(例如,自动查询离请求者位置最近的这种服务类型的实例);
●负载平衡策略(例如,找到提供所请求服务的最少加载的实例);和/或
●安全策略(例如,检查该终端是否有权使用所请求的服务类型,例如互联网访问,或者例如检查终端用户是否有权在当天的这个时间在该特定打印机上打印,或者例如强制用户使用特定的文件服务器)。
此外,也可以仅将新服务通知传播给之前表示其感兴趣的客户端(计算设备12和16)。换句话说,即使不能找到合适的服务候选者,在某个时刻t1捕获的搜索请求可以被保存一段时间Δt。如果在t1+Δt之前的稍后某时间点接收到与之前的搜索请求匹配的通知请求,则该通知可以直接传播到感兴趣的客户端。这将具有加速服务或设备发现的其他好处,而不会用没有客户感兴趣的通知堵塞网络10。使用这种基于兴趣的过滤,即仅向可用的服务候选者传播请求并且仅向感兴趣的各方传播通知可能会随着时间的推移在应用层模拟有效的多播树,而不需要任何多播网络服务。
参见图2-4,描述了关于在网络10中如何支持来自UPnP SD簇的SSDP的非限制性示例。在初始阶段,部署SD服务节点18,用于支持IP主机上的UPnP SD簇,该IP主机作为具有IP地址SD_Server_IP并在所有相关端口上监听UPnP的SD服务器。在某初始阶段,SRSC被部署为在服务器30上实现的控制器顶端的控制应用。SRSC配置有UPnP SD服务器(SD_Server_IP)的地址。在本说明书中省略了配置机制,由于其为本领域技术人员已知的。事实上,配置可能是手动的,或者本身可以依赖于一些自动配置机制。
当SRSC中的UPnP支持被激活(在其GUI上,作为选项,作为插件添加的结果,等等),SRSC首先使用控制器API(例如,服务器30的NBI)来选择拓扑相关的交换机(例如,所有边缘交换机,即网络节点12和16,或例如用户设备,诸如打印机的网络设备等)。然后,SRSC控制控制器API在所有选择的交换机中安装描述所有UPnP SSDP消息(这里以IPv4为例)的共同特征的转发规则,以便能够在所述交换机内匹配所有SSDP初始请求:
匹配:
IPv4目的地址:239.255.255.250
UDP目的端口:1900
动作:
重定向到:<SD_Server_IP>
在此示例中,IPv4目的地址和UDP端口是UPnP SSDP消息的特征。SRSC定义一个动作域,使得所有匹配的数据包被重定向到UPnP SD服务器(SD_Server_IP)。在OF中,可以使用可选的Set-Field动作完成此操作。在这方面,应当注意,替换IP目的地址将触发按规范的UDP循环冗余码校验(Cyclic Redundancy Check,CRC)域的自动重新计算。
在下一阶段,某个时刻,一些新的计算设备启动,或者终端连接到网络10,或者新的服务在诸如计算设备12或16的已经连接到网络10的设备上变得可用。在任何情况下,使用如图3所示的相应的SSDP机制来通知新的设备/服务。可以是多播数据包(具有多播MAC地址)或广播数据包(具有广播MAC地址)的第一个传入的SSDP数据包(图3中标记为(1))与预先安装在OF交换机中的规则相匹配。因此,OF交换机按照匹配规则的动作的指示操作,并更改整个数据包,从而该数据包作为单播数据包(具有单播MAC地址)被重定向到SD服务器(图3中标记为(2)的数据包),SD服务器现在将该服务注册到其内部服务位置注册表中,即按照服务类型(其中服务类型在相应的SD簇中指定)存储该服务的所有实例的位置(例如UPnP中的URL)的数据库。可选地,如果最近捕获到先前的对相同服务类型的搜索,则SD服务器现在可以将此消息转发到所有感兴趣的端点(按照UPnP规范语言为“控制点”),加速了将建议和请求方放在一起。
在下一阶段,某一时刻,新设备或现有设备上的最近启动的应用开始搜索先前通知的如图4所示的(备注:由于该示例正在使用UPnP,所以使用“控制点”概念,这是UPnP中符合规范的概念,通常指的是寻找要使用的服务的应用程序和/或设备——图4中的“新控制点”)服务类型。由于传入的搜索请求(图4中的事件(1))匹配相同的预先安装的规则,因此以与先前描述的相同的方式(图3中的事件(2))重定向到SD服务器。在此示例中,SD服务器按定义特征支持UPnP和SSDP。SD服务器使用其集成的SSDP功能来解析传入的请求并将其分类为搜索请求。因此,这导致服务位置注册表查询,其应该产生所请求的服务类型的所有注册的实例。SD服务器现在可以应用本地策略,并根据该策略为请求实体选择最佳匹配服务候选。然后,SD服务器使用其SSDP功能来构造符合规范的答复,并直接发送(作为单播)到原始请求者(图4中的事件(3))。
SRSC和SD Server两者都可以具有模块化设计。基本的SRSC和SD服务器功能将由单独的取决于SD的插件扩展,如用于UPnP的插件,用于zeroconf簇的插件,又例如DHCP的插件。在该示例中,SD服务器非常适合作为虚拟网络功能(virtual network function,VNF)的实现,即,符合当前的欧洲电信标准化协会(European Telecommunications SdandardsInstitute,ETSI)网络功能虚拟化(Network Functions Virtualisation,NFV)计划规范的VNF。要注意,这并不影响SD服务器的内部工作,然而通过指示SRSC关于所有新的可用的SD服务器实例,即关于SD服务器的每个新位置,可以容易地支持SD服务器移动性和弹性(NFV属性)。
在下文中,参考图5-7描述另一示例,其使用SRSC和SSCA,两者都作为SDN控制应用部署在服务器30上实现的控制器之上。在初始阶段,根据可用的控制器机制,具有支持UPnPSD簇的SSCA被部署在服务器30上实现的控制器之上。例如,SSCA可以使用服务器30的NBI,例如JSON和/或暴露于例如泛光灯(Floodlight)的Java API。SSCA支持所有其支持的特定发现协议(在本例中为UPnP)。SSCA可能能够将进入服务器30的所有数据包订阅为“packet_ins”,并且可以选择处理其感兴趣的那些数据包。在本示例中,SSCA处理所有与支持的SD簇相关的数据包,并且可以忽略其他的。
在某初始阶段,根据可用的控制器机制,SRSC作为控制应用被部署在控制器之上。SRSC被配置为使用控制器上的SSCA。省略配置机制,由于其为本领域技术人员已知的。特别地,配置机制可以是手动的,或者本身可以依赖于内部控制器规定(例如,控制应用可以能够利用控制器注册)。例如,在控制器的泛光灯实现中,这可以通过两个应用注册表文件来完成,一个告诉控制器要编译哪个应用程序,一个告诉它将哪些应用程序主动加载到执行环境中。
当SRSC中的UPnP支持被激活(通过其GUI,作为选项,作为插件添加的结果等),SRSC首先使用控制器API来选择如图5所示的拓扑相关的交换机(例如,所有边缘交换机,即连接到一些终端的交换机,例如用户设备,诸如打印机的网络设备,等)。然后,SRSC使用控制器API安装所有在选择的交换机中(在图5中,仅显示交换机“A”,以使示例不难理解)描述所有UPnP SSDP消息的共同特征的转发规则(此处使用以IPv4为例),以便能够匹配上述交换机内的所有SSDP初始请求:
匹配:
IPv4目的地址:239.255.255.250
UDP目的端口:1900
动作:
将Packet_in提升到控制器
在此示例中,IPv4目的地址和UDP端口是UPnP SSDP消息的特征。SRSC定义了一个动作域,使得捕获了所有匹配的数据包并将其重定向到控制器。在OF中,可以使用强制“输出到控制器”的动作完成此操作,从而导致发送OFPT_PACKET_IN OF消息。值得注意的是,这一步骤并不是强制性的。这是因为如果它们没有被分配如何处理数据包的任何特定规则(数据包不“匹配”规则),OF交换机通常会使用输出到控制器的操作将所有未知流重定向到控制器。虽然可以使用这种机制,但可能存在缺点:
●其不够精确而导致更高的控制器负载;
●容易导致不易发现的误解和错误,特别是如果控制器上的其他SDN应用程序定义了与相同流相匹配的冲突规则(例如,多播数据包的更精确规则可能涵盖某些SD簇消息)。
因此,如上所述,本示例清楚地说明了处理使用SRSC SD簇注册的控制器所需的确切流程。此外,出于安全原因,所有未知/未定义的流可能会按默认被丢弃,而不是重定向到控制器。
在下一阶段,某一时刻,某些新设备启动,或终端连接到网络10,或者新的服务在已经连接到网络10的设备上变得可用。在任何情况下,使用根据图6事件(1)的相应的SSDP机制通知新的设备/服务。第一个传入的SSDP数据包(在图6中由(1)标记)与OF交换机中预先安装的规则相匹配。因此,OF交换机按照匹配规则的动作的指示操作,并将整个数据包重定向到控制器(在图6中的(2)中标记为数据(DATA))。
整个原始数据包可以作为载荷包含在OFPT_PACKET_IN内。在服务器30上作为控制器应用程序运行的SSCA接收该packet_in并将该服务识别并注册到其内部服务位置注册表中,即按服务类型(其中服务类型在相应的SD簇中指定)存储此服务的所有实例的位置(例如,UPnP中的URL)的数据库。可选地,如果最近捕获到先前的对相同服务类型的搜索,则SSCA现在可以将该消息转发到所有感兴趣的端点(按UPnP规范语言为“控制点”),加速了提议和请求方匹配在一起。
在下一阶段,某一时刻,新设备或现有设备上的最近启动的应用开始搜索先前通知的服务类型,如图7所示。由于传入的搜索请求(图7中的事件(1))匹配相同的预先安装的规则,因此以与先前描述的相同的方式(图6中的事件(2))重定向到控制器。相当于前一阶段,控制器从OFPT_PACKET_IN消息中提取数据,并将它们与接收情况一起交给注册用于此事件的控制应用程序,此处为SSCA(图7中的事件(3))。
在此示例中,SSCA特征支持UPnP,因此支持SSDP。SSCA使用其集成的SSDP功能来解析传入的数据并将其分类为搜索请求。这导致服务位置注册表查询,并应该产生所有的所请求的服务类型的注册实例。SSCA现在可以应用本地策略,并根据该策略为请求实体选择最佳匹配服务候选。然后,SSCA使用其SSDP功能来构造符合规范的答复并将其直接发送(作为单播)到原始请求者(图7中的事件(4))。
另外应注意的是,SRSC和SSCA是功能实体。因此,其实现可以是结合SRSC和SSCA功能的单个控制应用程序。
Claims (15)
1.一种在软件定义网络SDN(20)中重定向服务或设备发现SD消息的方法,所述SDN(20)包括多个网络节点(14、18、26、28),一个或多个SD服务节点(22、24)以及服务器(30),所述方法包括:
所述服务器(30)指示所述多个网络节点(14、18、26、28)中的一个或多个网络节点(14、18、26、28)将接收的广播或多播SD消息作为单播或多播SD消息重定向到一个或多个选择的SD服务节点(22、24)。
2.根据权利要求1所述的方法,其中所述服务器(30)指示所述一个或多个网络节点(14、18、26、28)中的每一个以一组重定向规则来更新其流表,每个流表定义要被应用于到达相应网络节点(14、18、26、28)的消息的转发规则。
3.根据权利要求1或2所述的方法,还包括:
所述服务器(30)通过分析所述SDN(20)的网络拓扑确定所述一个或多个网络节点(14、18、26、28);以及
所述服务器(30)选择所述一个或多个网络节点(14、18、26、28)中的至少一个,其中每个所选择的网络节点(14、18、26、28)形成所述SDN(20)的端点,从而将接收的广播或多播SD消息作为单播或多播SD消息重定向到所述一个或多个所选择的SD服务节点(22、24)。
4.根据权利要求1至3中任一项所述的方法,所述方法还包括:
所述一个或多个所选择的SD服务节点(22、24)中的一个SD服务节点(22、24)接收重定向的SD消息;
所述一个SD服务节点(22、24)基于所接收的SD消息的服务类型,确定提供或请求所述服务类型的服务的计算设备(12、16);以及
所述一个SD服务节点(22、24)向所述SD消息的发送者发送对所述SD消息的单播响应,所述响应指示所确定的计算设备(12、16);或者,所述一个SD服务节点(22、24)将所述SD消息转发到所确定的计算设备(12、16),所述计算设备之后直接回复所述SD消息的发送者;以及
所述一个SD服务节点(22、24)存储将提供服务和请求服务链接到计算设备(12、16)的查询表;
其中,所述查询表由所述一个SD服务节点(22、24)基于所接收的SD消息进行更新。
5.根据权利要求1至4中任一项所述的方法,其中所述服务器(30)包括所述一个或多个SD服务节点(22、24)。
6.根据权利要求1至5中任一项所述的方法,其应用于网络(10),所述网络(10)包括所述SDN(20)和连接到所述SDN(20)的端点的多个计算设备(12、16)并且运行服务或设备发现协议,其中所述服务或设备发现协议的类型是UPNP、SSDP、zeroconf、SDP、Bonjour或DLNA之一。
7.一种在软件定义网络SDN(20)中使用的服务器(30),所述服务器(30)维护一个或多个网络节点(14、18、26、28)的消息转发规则的集中视图,并且用于指示所述一个或多个网络节点(14、18、26、28)更新其流表,每个流表定义要被应用于到达相应网络节点(14、18、26、28)的消息的转发规则,以使得将所述一个或多个网络节点(14、18、26、28)接收的广播或多播SD消息作为单播或多播SD消息重定向到一个或多个所选择的SD服务节点(22、24)。
8.根据权利要求7所述的服务器(30),其中所述服务器(30)用于分析所述SDN(20)的拓扑,通过分析所述SDN(20)的拓扑确定所述一个或多个网络节点,并且用于选择形成所述SDN(20)的端点的至少一个网络节点(14、18、26、28),以将接收的广播或多播SD消息作为单播或多播SD消息重定向到一个或多个所选择的SD服务节点(22、24)。
9.根据权利要求7或8所述的服务器(30),其中所述服务器用于指示所述一个或多个网络节点(14、18、26、28),以在学习激活SDN中新的SD簇时安装新的转发规则。
10.一种在软件定义网络SDN(20)中使用的服务或设备发现SD服务节点(22、24),所述SD服务节点(22、24)用于:
接收SD消息;
基于所接收的SD消息的服务类型,确定提供或请求所述服务类型的服务的计算设备(12、16);以及
向如所述SD消息中指示的所述SD消息的发送者发送对所述SD消息的单播响应,所述单播响应指示所确定的计算设备(12、16);和/或,将所述SD消息转发到所确定的计算设备(12、16);
存储将提供服务和请求服务链接到计算设备(12、16)的查询表;以及
基于接收的SD消息更新所述查询表。
11.一种在软件定义的网络SDN(20)中使用的网络节点(14、18、26、28),所述网络节点(14、18、26、28)用于接收将接收的广播或多播SD消息作为单播或多播SD消息重定向到一个或多个所选择的SD服务节点(22、24)的指令。
12.根据权利要求11所述的网络节点(14、18、26、28),其中,所述网络节点(14、18、26、28)用于接收利用一组重定向规则来更新其流表的指令,以响应从服务器(30)接收的控制消息,其中所述流表定义要被应用于到达所述网络节点(14、18、26、28)的消息的转发规则。
13.根据权利要求12所述的网络节点(14、18、26、28),其中所述网络节点(14、18、26、28)用于分析接收的SD消息并且选择一个或多个用于基于分析结果和重定向规则的设定进行重定向的SD服务节点(22、24)。
14.根据权利要求11至13中任一项所述的网络节点(14、18、26、28),其中所接收的广播或多播SD消息符合UPNP、SSDP、zeroconf、SDP、Bonjour或DLNA服务或设备发现协议。
15.一种网络(10),包括:
包括根据权利要求7或8所述的服务器(30)的软件定义网络SDN(20),和/或根据权利要求9或10所述的一个或多个SD服务节点(22、24),以及根据权利要求11至14中任一项所述的多个网络节点(14、18、26、28);以及
连接到所述SDN(20)的端点并且运行服务或设备发现协议的至少两个计算设备(12、16),其中所述服务或设备发现协议的类型是UPNP、SSDP、zeroconf、SDP、Bonjour或DLNA之一。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP2015/069817 WO2017036505A1 (en) | 2015-08-31 | 2015-08-31 | Redirection of service or device discovery messages in software-defined networks |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN107852335A true CN107852335A (zh) | 2018-03-27 |
Family
ID=54145729
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201580081546.7A Pending CN107852335A (zh) | 2015-08-31 | 2015-08-31 | 软件定义网络中的服务或设备发现消息的重定向 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20180191600A1 (zh) |
| EP (1) | EP3311528A1 (zh) |
| CN (1) | CN107852335A (zh) |
| WO (1) | WO2017036505A1 (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108768711A (zh) * | 2018-05-18 | 2018-11-06 | 新华三技术有限公司 | 一种网络管理方法、装置及设备 |
| CN115136547A (zh) * | 2020-02-19 | 2022-09-30 | 海拉有限双合股份公司 | 用于在具有预过滤单元的车辆中提供至少一种服务的车辆组件 |
| CN119728704A (zh) * | 2025-02-27 | 2025-03-28 | 浪潮软件科技有限公司 | 一种基于p2p的数据交换方法 |
Families Citing this family (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9225638B2 (en) | 2013-05-09 | 2015-12-29 | Vmware, Inc. | Method and system for service switching using service tags |
| US10225137B2 (en) | 2014-09-30 | 2019-03-05 | Nicira, Inc. | Service node selection by an inline service switch |
| US10320679B2 (en) | 2014-09-30 | 2019-06-11 | Nicira, Inc. | Inline load balancing |
| US9825810B2 (en) | 2014-09-30 | 2017-11-21 | Nicira, Inc. | Method and apparatus for distributing load among a plurality of service nodes |
| US10609091B2 (en) | 2015-04-03 | 2020-03-31 | Nicira, Inc. | Method, apparatus, and system for implementing a content switch |
| EP3345341A1 (en) | 2015-10-20 | 2018-07-11 | Huawei Technologies Co., Ltd. | Direct replying actions in sdn switches |
| US10581697B2 (en) * | 2017-03-24 | 2020-03-03 | Dell Products L.P. | SDN controlled PoE management system |
| US10848413B2 (en) * | 2017-07-12 | 2020-11-24 | Nicira, Inc. | Self-expansion of a layer 3 network fabric |
| US10805181B2 (en) | 2017-10-29 | 2020-10-13 | Nicira, Inc. | Service operation chaining |
| US10797910B2 (en) | 2018-01-26 | 2020-10-06 | Nicira, Inc. | Specifying and utilizing paths through a network |
| US10805192B2 (en) | 2018-03-27 | 2020-10-13 | Nicira, Inc. | Detecting failure of layer 2 service using broadcast messages |
| US11595250B2 (en) | 2018-09-02 | 2023-02-28 | Vmware, Inc. | Service insertion at logical network gateway |
| US11604666B2 (en) | 2019-02-22 | 2023-03-14 | Vmware, Inc. | Service path generation in load balanced manner |
| US11863468B2 (en) * | 2019-04-19 | 2024-01-02 | Marvell Asia Pte Ltd | Control of ethernet link-partner GPIO using OAM |
| US11283717B2 (en) | 2019-10-30 | 2022-03-22 | Vmware, Inc. | Distributed fault tolerant service chain |
| US11140218B2 (en) | 2019-10-30 | 2021-10-05 | Vmware, Inc. | Distributed service chain across multiple clouds |
| US11223494B2 (en) | 2020-01-13 | 2022-01-11 | Vmware, Inc. | Service insertion for multicast traffic at boundary |
| US11659061B2 (en) | 2020-01-20 | 2023-05-23 | Vmware, Inc. | Method of adjusting service function chains to improve network performance |
| US11153406B2 (en) | 2020-01-20 | 2021-10-19 | Vmware, Inc. | Method of network performance visualization of service function chains |
| US11528219B2 (en) | 2020-04-06 | 2022-12-13 | Vmware, Inc. | Using applied-to field to identify connection-tracking records for different interfaces |
| US11824640B2 (en) | 2020-06-17 | 2023-11-21 | Hewlett Packard Enterprise Development Lp | System and method for reconfiguring a network using network traffic comparisions |
| US11362849B1 (en) * | 2020-11-23 | 2022-06-14 | Cisco Technology, Inc. | SD-WAN multicast replicator selection centralized policy |
| US11611625B2 (en) | 2020-12-15 | 2023-03-21 | Vmware, Inc. | Providing stateful services in a scalable manner for machines executing on host computers |
| US11734043B2 (en) | 2020-12-15 | 2023-08-22 | Vmware, Inc. | Providing stateful services in a scalable manner for machines executing on host computers |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102098167A (zh) * | 2010-12-29 | 2011-06-15 | 杭州华三通信技术有限公司 | 一种组播流转发方法及其设备和系统 |
| CN103248724A (zh) * | 2013-04-19 | 2013-08-14 | 中国(南京)未来网络产业创新中心 | 一种基于sdn控制器的dhcp广播处理方法 |
| US20130322443A1 (en) * | 2012-05-29 | 2013-12-05 | Futurewei Technologies, Inc. | SDN Facilitated Multicast in Data Center |
| WO2014041550A1 (en) * | 2012-09-11 | 2014-03-20 | Hewlett-Packard Development Company, L.P. | Discovering ip multicast group memberships in software defined networks |
| CN104486095A (zh) * | 2014-12-22 | 2015-04-01 | 上海斐讯数据通信技术有限公司 | Sdn控制器及组播控制方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080267144A1 (en) * | 2007-04-26 | 2008-10-30 | Motorola, Inc. | System and method for managing broadcast and/or multicast based communication sessions for mobile nodes |
| US20150327052A1 (en) * | 2014-05-08 | 2015-11-12 | Benu Networks, Inc. | Techniques for Managing Network Access |
| US9705694B2 (en) * | 2015-04-24 | 2017-07-11 | Fortinet, Inc. | Extension of Wi-Fi services multicast to a subnet across a Wi-Fi network using software-defined networking (SDN) to centrally control data plane behavior |
| KR20170023493A (ko) * | 2015-08-24 | 2017-03-06 | 한국전자통신연구원 | 소프트웨어 정의 네트워크와 레거시 네트워크가 연동된 환경에서의 네트워크 서비스 제어 장치 및 방법 |
-
2015
- 2015-08-31 EP EP15763842.0A patent/EP3311528A1/en not_active Withdrawn
- 2015-08-31 CN CN201580081546.7A patent/CN107852335A/zh active Pending
- 2015-08-31 WO PCT/EP2015/069817 patent/WO2017036505A1/en not_active Ceased
-
2018
- 2018-02-27 US US15/906,167 patent/US20180191600A1/en not_active Abandoned
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102098167A (zh) * | 2010-12-29 | 2011-06-15 | 杭州华三通信技术有限公司 | 一种组播流转发方法及其设备和系统 |
| US20130322443A1 (en) * | 2012-05-29 | 2013-12-05 | Futurewei Technologies, Inc. | SDN Facilitated Multicast in Data Center |
| WO2014041550A1 (en) * | 2012-09-11 | 2014-03-20 | Hewlett-Packard Development Company, L.P. | Discovering ip multicast group memberships in software defined networks |
| CN103248724A (zh) * | 2013-04-19 | 2013-08-14 | 中国(南京)未来网络产业创新中心 | 一种基于sdn控制器的dhcp广播处理方法 |
| CN104486095A (zh) * | 2014-12-22 | 2015-04-01 | 上海斐讯数据通信技术有限公司 | Sdn控制器及组播控制方法 |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108768711A (zh) * | 2018-05-18 | 2018-11-06 | 新华三技术有限公司 | 一种网络管理方法、装置及设备 |
| CN108768711B (zh) * | 2018-05-18 | 2022-03-01 | 新华三技术有限公司 | 一种网络管理方法、装置及设备 |
| CN115136547A (zh) * | 2020-02-19 | 2022-09-30 | 海拉有限双合股份公司 | 用于在具有预过滤单元的车辆中提供至少一种服务的车辆组件 |
| CN119728704A (zh) * | 2025-02-27 | 2025-03-28 | 浪潮软件科技有限公司 | 一种基于p2p的数据交换方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3311528A1 (en) | 2018-04-25 |
| WO2017036505A1 (en) | 2017-03-09 |
| US20180191600A1 (en) | 2018-07-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107852335A (zh) | 软件定义网络中的服务或设备发现消息的重定向 | |
| EP2759116B1 (en) | Services controlled session based flow interceptor | |
| US9806944B2 (en) | Network controller and a computer implemented method for automatically define forwarding rules to configure a computer networking device | |
| CN110313162B (zh) | 促进在网络环境中向多个接收者的内容递送的系统和方法 | |
| EP2866389B1 (en) | Method and device thereof for automatically finding and configuring virtual network | |
| US9049209B2 (en) | Methods and apparatus to route a communication session in an internet protocol (IP) multimedia subsystem (IMS) network | |
| JP2022517176A (ja) | ローカルエリアネットワーク(lan)をサポートする方法および装置 | |
| CN111566997B (zh) | 网络切片使用 | |
| US20160065503A1 (en) | Methods, systems, and computer readable media for virtual fabric routing | |
| US20110002240A1 (en) | System and method for creating a transitive optimzed flow path | |
| CN102238226A (zh) | 在以内容为中心的网络上的会话迁移 | |
| US10075354B2 (en) | Identification of servers by common wide area network addresses | |
| US8553685B2 (en) | Session border control migration | |
| US10567950B2 (en) | Content delivery network request handling in wireless communication systems | |
| KR20130136530A (ko) | 원격 서버에 질의하는 것에 의한 플로우 라우팅 프로토콜 | |
| CN108702324B (zh) | 用于用户端lan扩展的装置 | |
| JP2016149701A (ja) | ネットワークシステムおよびパケット転送方法 | |
| Wang et al. | SD-ICN: An interoperable deployment framework for software-defined information-centric networks | |
| US9763135B1 (en) | Load balancing with mobile resources | |
| Jeong et al. | Lisp controller: a centralized lisp management system for isp networks | |
| US10439933B2 (en) | Isolating services across a single physical network interface | |
| CN100542167C (zh) | 基于igrs协议的主从设备组之间无线路由实现方法 | |
| CN105592176A (zh) | 一种信息处理方法、网络设备及系统 | |
| CN108933836A (zh) | 一种在网络中重定向服务或设备消息的方法 | |
| US20070091875A1 (en) | Method and System For Device Mobility Using Application Label Switching In A Mobile Communication Network |
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 | ||
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20180327 |