具体实施方式
下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例,然而应当理解的是,本公开可以通过各种形式来实现,而且不应该被解释为限于这里阐述的实施例,相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是,本公开的附图及实施例仅用于示例性作用,并非用于限制本公开的保护范围。
在此使用的术语“服务”是指SDN网络中提供的任意适当控制功能或应用。服务的示例包括但不限于,开放最短路径优先(OSPF)、因特网组管理协议(IGMP)、路径计算引擎(PCE)、拓扑计算和访问控制防火墙、数据分析、人工智能(AI)等等。
在此使用的术语“SDN控制器”是指能够在SDN网络中提供服务的任意适当设备。SDN控制器的示例包括但不限于以下一个或多个:主机、刀片服务器、个人计算机(PC)、路由器、交换机、膝上型计算机、平板式计算机,等等。
在此使用的术语“网络设备”是指SDN网络中能够访问服务的任意适当设备,诸如SDN交换机或其他网络实体。
在此使用的术语“电路”是指以下的一项或多项:
(a)仅硬件电路实现方式(诸如仅模拟和/或数字电路的实现方式);以及
(b)硬件电路和软件的组合,诸如(如果适用):(i)模拟和/或数字硬件电路与软件/固件的组合,以及(ii)硬件处理器的任意部分与软件(包括一起工作以使得诸如OLT或其他计算设备等装置执行各种功能的数字信号处理器、软件和存储器);以及
(c)硬件电路和/或处理器,诸如微处理器或者微处理器的一部分,其要求软件(例如固件)用于操作,但是在不需要软件用于操作时可以没有软件。
电路的定义适用于此术语在本申请中(包括任意权利要求中)的所有使用场景。作为另一示例,在此使用的术语“电路”也覆盖仅硬件电路或处理器(或多个处理器)、或者硬件电路或处理器的一部分、或者其随附软件或固件的实现方式。例如,如果适用于特定权利要求元素,术语“电路”还覆盖基带集成电路或处理器集成电路或者OLT或其他计算设备中的类似的集成电路。
在此使用的术语“包括”及其变形是开放性包括,即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”;术语“另一实施例”表示“至少一个另外的实施例”。其他术语的相关定义将在下文描述中给出。
如上所述,在SDN网络管理中,为了改进单个SDN控制器的网络管理性能以及提高可靠性和可扩展性,多个SDN控制器可以作为SDN控制器集群协同操作,以便使用分布式控制器技术来管理底层SDN交换机。SDN控制器集群具有动态性,这归因于集群成员的服务中断或者新成员的加入。负载均衡或者用于网络优化的其他策略要求也会导致SDN控制器集群的动态性。
为了使SDN控制器集群正常工作,一方面,多个分布式SDN控制器应相互协作,以便维护SDN控制器之间的数据和状态一致性,以及动态管理SDN控制器集群中成员的加入/离开等。另一方面,SDN控制器集群需要管理分布式SDN控制器的负载均衡,从而在动态环境中分配适当的SDN控制器与底层SDN交换机通信并且对底层SDN交换机进行管理。
因此,以下多个方面的SDN控制器集群的管理是非常重要的:有效地管理SDN控制器集群中成员的动态加入/离开,在整个集群中保持数据/状态的一致性,以及根据处理能力(例如,负载状态)或者地理位置(用于延迟优化)等等其他策略动态分配适当的SDN控制器来管理底层SDN交换机。
图1示出了基于SDN控制器主机构建集群的SDN网络100的示例架构。在网络100中,集群105由多个SDN控制器110-1、110-2……110-N(统称为“SDN控制器110”)组成。管理器(例如,Zookeeper)115与SDN控制器110交互,以对其进行监控。管理器115还可以与负载均衡器120交互,以便根据处理能力(例如,负载状态)或其他策略动态地分配适当的SDN控制器来管理底层网络设备(例如,SDN交换机)125-1、125-2……125-M。为了维持集群105内的数据一致性,SDN控制器110之间具有东西向接口连接130-1……130-K(统称为“接口连接130”),用于SDN控制器110之间的通信和同步。N、M和K为任意适当正整数。
除了通过接口连接130来实现数据同步之外,还有一种以数据为中心的方式。该方式采用数据和逻辑分离的架构,使用共享数据存储库来保存SDN控制器110的状态和操作数据,从而在SDN控制器110切换情况下确保了数据的一致性。
在网络100中,管理器115可以管理在集群105中的SDN控制器110的加入和离开。例如,管理器115可以监视其数据结构(例如Zookeeper节点或“znodes”列表)中的由SDN控制器110创建的“znodes”。如果某个SDN控制器110停止服务,与其相对应的“znode”将从受监视的“znodes”列表中删除,从而触发相关的集群管理操作。
为了根据负载均衡等优化策略动态地分配适当的SDN控制器110来管理底层网络设备125,如图1所示,负载均衡器120负责将网络设备125的请求分发给合适的SDN控制器110。在网络100中,负载均衡器120的虚拟互联网协议(IP)地址被发布给网络设备125。在网络设备125访问该虚拟IP地址时,来自网络设备125的通信将被转换并且重定向到集群105中的SDN控制器110的实际IP地址。传统上,负载均衡是基于SDN控制器主机的。负载均衡算法可以采用轮询算法或哈希(Hash)算法等等。
图1所示的基于管理器115(例如,Zookeeper)的集群管理方式,需要数据一致性、负载均衡以及虚拟IP转换和重定向等多种技术集成在一起,并且相互协作。而且,负载均衡器120需要高的业务处理能力,以避免成为业务瓶颈。这使得系统过于复杂,很难进行部署和维护。
发明人注意到,这种基于SDN控制器主机建立的集群要求每个SDN控制器完全相同,也即,能力相同,服务也相同。然而,各SDN控制器在处理能力、存储能力和网络带宽等方面可能实际上并不相同。
发明人还注意到,服务和数据的提供是网络互连的本质,以主机为中心的连接只是用以提供服务和数据的网络互连的中介过程。在不同SDN控制器中提供不同服务将为SDN控制器110的配置增加极大的灵活性。而且,服务是SDN控制器中管理底层网络设备的基本控制功能。在实际应用中,特别是对于NFV、云和微服务开发,功能或服务通常是需要优化或纠正的警告或故障的基本粒度。因此,存在建立服务级别的集群的需求,这种集群可以管理服务级别的加入或离开。
本公开的实施例提出了一种面向服务的SDN集群管理机制。该机制以服务中心,形成SDN服务集群而不是SDN控制器主机集群。这种以服务为中心的机制引入了服务解析系统(SRS)。SRS维护至少SDN网络中的服务的标识与服务的各个实例(例如,在SDN控制器上运行)的访问地址之间的关联。在从网络设备接收到针对服务的请求之后,基于此关联,SRS将来自网络设备的服务请求解析成相应的服务实例的访问地址。由此,网络设备可以使用该访问地址来访问相应的服务。
根据本公开的实施例,SDN控制器可以在服务级别上协作,并且可以在服务级别基于诸如负载均衡和地理位置优化等的策略来动态地为管理底层网络设备(例如,SDN交换机)分配服务。以此方式,可以实现更精确的SDN控制器的管理以及SDN控制器提供的服务到底层网络设备的分配。
例如,SRS可以进行服务解析以及确定诸如服务负载均衡和位置优化等策略,用以为底层网络设备找出的服务的路由定位器,例如能够提供服务的SDN控制器的访问地址(例如,IP地址)。SRS还可以动态维护服务标识和SDN控制器上运行的服务实例的访问地址(也即,服务所在的位置)之间的关联,动态管理服务集群中的服务加入和离开,实时地监控服务负载情况等等。
在这种SDN服务集群中,底层网络设备所需的服务可以通过服务的标识并且基于服务负载情况和/或例如地理位置优化或客户类别等其他附加路由策略被路由。服务及其标识是路由的基本因素。可以在集群中管理服务级别的加入或离开,管理服务粒度的负载均衡,并且可以根据网络设备所调用的服务来管理相关联的SDN控制器与网络设备之间的通信。另外,SDN控制器作为服务的容器可以随意地安装服务,这些服务可以相同,也可以不同。这种服务集群更具灵活性。
图2示出了根据本公开的某些实施例的SDN网络200的示例架构。网络200包括多个SDN控制器210-1、210-2……210-N(统称为SDN控制器210)。在每个SDN控制器210上运行一个或多个服务实例215-1、215-2……215-L(统称为“服务实例215”)。服务实例215可以被网络200中的底层网络设备225-1、225-2……225-L(统称为“网络设备225”)访问或调用。N、M和L为任意适当正整数。
在虚拟化和云技术的支持下,服务实例215可以被虚拟化,并且可以在SDN控制器210中的不同虚拟机中运行。SDN控制器210中的每个服务实例215都可以具有各自的告警、故障和负载状态等。
归因于SDN控制器210的不同配置以及各个SDN控制器210上服务实例215的动态变化,SDN控制器210可以不提供完全相同的服务。不同SDN控制210上的服务实例215可以执行相同或不同的功能或应用。
在图2所示的示例中,SDN控制器210-1上运行的服务实例215-1、SDN控制器210-2上运行的服务实例215-4以及SDN控制器210-3上运行的服务实例215-6执行相同的功能。SDN控制器210-1上运行的服务实例215-2与SDN控制器210-2上运行的服务实例215-5执行相同的功能。SDN控制器210-1上运行的服务实例215-3与SDN控制器210-N上运行的服务实例215-L执行相同的功能。如此,SDN控制器210的部署和服务配置具有极大的灵活性。各个SDN控制器210不需要提供完全相同的服务,也不需要都具有很高的容量。
在网络200中,每个服务及其实例215都具有相应的标识。该标识可以在网络200中是唯一的。例如,同一服务的不同实例具有相同的服务标识,不同服务的实例具有不同的服务标识。在图2所示的示例中,服务实例215-1、215-4和215-6具有服务标识A。服务实例215-2和215-5具有服务标识B,服务实例215-3和215-L具有服务标识C。可以采用当前已知以及将来开发的任意适当命名方式来对服务命名。作为示例,为了确保标识和服务的整体性,可以使用基于服务的软件映像的散列算法来产生唯一标识。
在网络200中,使用服务数据和逻辑分离架构和共享数据存储,来维护服务之间的数据一致性。例如,如图2所示,网络200中包括数据存储库230。数据存储库230作为共享数据存储库,可以与SDN控制器210交互,用于存储SDN控制器210上运行的服务实例的状态和操作数据等信息。数据存储库230的使用使得各个SDN控制器210中的服务实例215是无状态的,从而可以在动态环境中,例如在服务切换时,保持服务相关信息的一致性。
应当理解,仅仅出于示例而非限制的目的,在图2中示出了数据存储库230。在某些实施例中,可以不采用这种数据和逻辑分离的架构,而是SDN控制器210通过彼此之间的接口连接(例如图1中的接口连接130)来交互服务状态和操作数据等等,以维持数据的一致性。
网络200还包括服务解析系统(SRS)235。SRS 235负责服务解析,用于为请求服务的网络设备225确定该服务的访问地址。在本公开的各实施例中,SRS 235维护至少服务的标识与服务的各个实例215的访问地址(例如,运行相应实例215的SDN控制器210的IP地址或其他路由定位符)之间的关联。
在某些实施例中,SRS 235还可以考虑诸如负载均衡和位置优化等预定义的策略来选择供网络设备225访问的服务实例215。在这种情况下,SRS 235可以将服务实例215的状态或属性与服务标识以及服务实例215的访问地址绑定在一起。由此,可以基于预定义的策略来进行服务实例的选择,从而可以为策略管理和基于策略的服务选择提供了更大的可扩展性。
例如,SRS 235可以维护服务的标识、服务的各个实例215的访问地址以及服务实例215的属性(例如,负载情况)之间的关联。如此,SRS 235可以采用服务负载均衡相关的策略算法来找到最合适的服务实例。该关联可以表的形式存储于SRS 235本地或者SRS 235可访问的外部存储设备(未示出)中。
在某些实施例中,如图2所示,SRS 235通过与SDN控制器210交互(240)来建立上述关联。例如,SRS 235可以从SDN控制器210接收该SDN控制器210的路由地址(例如,IP地址)以及该SDN控制器210所支持的服务的标识,继而建立该路由地址与服务标识之间的关联。如果SRS 235还可以从SDN控制器210接收在该SDN控制器210上运行的服务实例的属性(例如,负载情况),SRS 235可以建立SDN控制器210的路由地址、服务的标识以及服务实例的属性之间的关联。
在某些实施例中,SRS 235可以对所建立的关联进行更新。例如,在SDN控制器210处激活新的服务,或者某个服务发生故障或停止时,SRS 235可以从SDN控制器210获得相关的信息,并且基于这些信息对关联进行更新。例如,SRS 235可以注册新激活的服务,或者注销停止的服务。
图3示出了根据本公开的某些实施例的SRS 235进行服务注册和监控的示例过程300。过程300包括服务注册和服务监控两个过程。服务注册过程可以在SDN控制器210激活阶段执行。例如,SDN控制器210-1在激活时可以向SRS 235注册(305)其自己的IP地址X以及所支持的服务的标识A、B和C。SDN控制器210-2可以向SRS 235注册(310)IP地址Y以及服务标识A和B。SDN控制器210-N可以向SRS 235注册(315)IP地址Z以及服务标识A和C。在框320,SRS 235建立各个IP地址X、Y和Z与服务标识A、B和C之间的关联。
服务监控阶段可以在SDN控制器210的操作阶段执行,用于监控SDN控制器210上运行的相应服务实例215的状态,例如,是否有新的服务实例被激活;或者监控服务实例215的属性,例如,是否某个已有的服务实例发生故障。该服务监控可以通过心跳机制来执行。例如,当SDN控制器210处于操作阶段时,SDN控制器210可以通过与SRS 235的心跳交互,周期性地(每秒)更新其服务状态(例如,服务加入或离开)和服务属性(例如,服务负载情况)。
如图3所示,SDN控制器210-1利用心跳交互来更新(325)服务实例215-1、215-2和215-3的状态和负载。SDN控制器210-2利用心跳交互来更新(330)服务实例215-4和215-5的状态和负载。SDN控制器210-N利用心跳交互来更新(335)服务实例215-6和215-L的状态和负载。325、330和335可以循环执行(340)。在框345,SRS 235可以将SDN控制器210上运行的各个服务实例215的负载添加到所建立的关联中。
该关联可以记录在如下的表1中。
表1
表1中存储了服务标识A、B和C、IP地址X、Y和Z以及相应服务实例215的负载情况(以百分比的形式来表示)的关联关系。
当新服务的加入(例如,添加或激活)或者已有服务离开(例如,解激活或发生故障)时,更新的服务状态将触发SRS 235中的相应关联关系的更改。例如,当SDN控制器210上的某个服务实例215被解激活或发生故障时,该服务实例215将被SRS 235注销。如图3所示,在框350,SRS 235可以在某个心跳交互失败时注销相应的服务实例215。通过频繁更新服务实例215的负载情况可以实时地在所建立的关联中反映服务负载情况的变化。
例如,在SDN控制器210-1上运行的服务实例215-2发生故障时,表1可以更新为如下的表2。
表2
| IP地址 |
服务标识 |
服务负载 |
| X |
A |
80% |
| X |
B |
20% |
| X |
C |
70% |
| Y |
A |
90% |
| Z |
A |
20% |
| Z |
C |
30% |
在表2中,与IP地址Y和服务标识B相关联的条目被删除。
下面继续参考图2,根据本公开的实施例,SRS 235从网络设备225接收(245)包含服务标识(例如,标识A)的服务请求。基于服务标识与相关服务实例215的访问地址之间的关联,SRS 235选择供网络设备225访问的访问地址。例如,在来自网络设备的服务请求中包含服务标识A的情况下,SRS 235可以基于服务标识A与服务实例215-1、215-4和215-6的访问地址之间的关联,选择服务实例215-6的访问地址。继而,SRS 235向网络设备225发送(250)所选择的访问地址。使用该访问地址,网络设备225可以与相应的SDN控制器210(例如,SDN控制器210-N)交互(255),以便访问或调用相应的服务实例215(例如,服务实例215-6)。
图4示出了根据本公开的某些实施例的网络设备225调用服务的示例过程400。如图4所示,网络设备225-1在框405准备调用标识为A的服务。在410,网络设备225-1向SRS235发送服务解析请求,其中包含服务标识A。在框415,SRS 235进行服务解析。例如,通过查找记录服务标识与服务实例的访问地址以及服务实例的负载情况之间的关联的表,确定SDN控制器210-N上的服务实例215-6可供网络设备225-1使用,并且将标识A解析为IP地址Z。在420,SRS 235向网络设备225-1发送服务解析响应,其中包含地址Z。根据该地址Z,网络设备225-1在425与SDN控制器210-N进行Openflow通信。可以采用当前已知和将来开发的任意适当Openflow通信技术。本公开的范围在此方面不受限制。在框430,SDN控制器210-N调用与标识A相对应的服务实例215-6。
接下来,在框435,网络设备225-2准备调用标识为C的服务。在440,网络设备225-2向SRS 235发送服务解析请求,其中包含服务标识C。在框445,SRS 235进行服务解析。在450,SRS 235向网络设备225-1发送服务解析响应,其中包含地址Z。根据该地址Z,网络设备225-2在455与SDN控制器210-N进行Openflow通信。在框460,SDN控制器210-N调用与标识C相对应的服务实例215-L。
对于网络设备225(例如,SDN交换机)而言,所请求的服务与位置(例如,提供该服务的SDN控制器210)无关。网络设备225不需要关心服务的具体位置,而只需通过服务标识向SRS 235请求服务。在从SRS 235获得服务位置时,网络设备225可以与目标SDN控制器210执行常规的通信(例如,Openflow通信),从而访问或调用相应的服务。
基于用于服务的提供的NFV和云开发,本发明的实施例在将服务作为新的网络架构的中心,并且将传统的基于SDN控制器主机的集群调整为基于服务的集群。在基于服务的集群中,将以更精确和高效的方执行服务故障转移和服务即插即用。这种基于服务的集群的在集群管理方面更具优势。
图5示出了根据本公开的实施例的基于服务的集群与传统的基于SDN控制器主机的集群在集群管理上的差异。如图5所示,在基于SDN控制器主机的集群505中,SDN控制器210-3上的某个服务实例215-7、215-8或215-9发生故障,将导致整个SDN控制器210-3的故障,即SDN控制器210-3中的所有服务将停止。
在基于服务的集群510中,如果SDN控制器210-3上运行的服务实例215-7发生故障,仅仅该服务实例215-7停止运行,而其他服务实例215-8和215-9则不会受到影响,可以继续为底层网络设备225服务。这种更精确的管理机制增强了SDN集群的冗余和保护能力,同时最大限度地降低了对集群处理能力的影响或SDN控制器210关闭的概率。
在这种以服务为中心的架构中,服务提供与SDN控制器无关,从而可以在动态的服务集群环境中提供服务配置和SDN控制器部署的灵活性,而无需在SDN控制器中部署完全相同的服务。在实际情况中,出于以下几方面的考虑而需要在SDN控制器中进行灵活且不同的服务部署,例如:
-SDN控制器的不同处理能力
-服务对地理位置的不同延迟敏感度
-服务的不同负载需求
-服务的不同安全保护级别
-集群的成本优化
图6示出了根据本公开的某些实施例的服务在SDN控制器上的示例部署。在此示例中,集群605包括三个SDN控制器210-1、210-2和210-N,其IP地址分别为X,Y和Z。假设三个SDN控制器210-1、210-2和210-N具有不同的处理能力、不同的地理接近度和不同的成本,如下面的表3所示。
表3
| SDN控制器IP地址 |
处理能力 |
地理接近度 |
成本 |
| X |
高 |
好 |
100% |
| Y |
中 |
好 |
70% |
| Z |
低 |
差 |
40% |
集群605中可以提供IGMP、IGMP、访问控制和数据分析等服务。每个服务对负载、延迟和安全性都有不同的要求,如下面的表4所示。
表4
| 服务 |
延迟敏感度 |
安全级别 |
服务负载 |
| IGMP |
高 |
低 |
中 |
| IGMP |
低 |
中 |
低 |
| 访问控制 |
低 |
低 |
中 |
| 数据分析 |
低 |
低 |
低 |
如图6所示,为了满足延迟敏感的IGMP的要求,例如快速切换,IGMP服务可以部署在SDN控制器210-1和210-N中(例如,服务实例215-10和215-17),因为其具有良好的地理接近度。为了对数据分析服务的高服务负载进行均衡,SDN控制器210-1、210-2和210-N都将安装该服务的服务实例215-12、215-15和215-18。而且,访问控制服务也将部署到所有三个SDN控制器210-1、210-2和210-N(例如,服务实例215-13、215-16和215-19),以提供更好的冗余,从而防止服务失败或黑客攻击。由于PCE服务对负载、安全性和延迟具有较低要求,可以仅在SDN控制器210-1和210-2中部署该服务的实例215-11和215-14。与基于SDN控制器主机的集群(需要三个相同的高成本SDN控制器来部署所有这些服务)相比,基于服务的集群605中的SDN控制器的总成本得到优化,从300减少到210,降低了30%。
与复杂的多技术集成相比,SRS通过服务标识和服务位置的简单绑定为集群管理和服务解析提供了简单的解决方案。而且,由于没有业务经过SRS,因此负载均衡解决方案中的潜在性能瓶颈得到避免。此外,诸如负载状态等这些传统上用于为底层网络设备(例如,SDN交换机)选择和分配SDN控制器主机的策略,随着集群管理转变为服务级别,将变得更加精确,从而可以实现更精细的策略管理和执行。例如,根据传统的基于SDN控制器主机的策略,在某个SDN控制器的总负载过高时,SDN控制器主机将无法接受新的任务。但是,如果采用了服务级别的策略,该SDN控制器主机中的低负载服务仍可接受新任务。这使得SDN控制器的处理能力得到了最大化应用。而且,SRS可以在所建立的关联关系中添加更多属性,例如服务负载、客户类别和地理位置等等。因此,SRS可以很容易地被扩展,以应对各种新的政略,从而实现更复杂且更精确的服务选择。与传统的基于SDN控制器主机的集群相比,根据本公开的实施例的基于服务的集群更加简单性,并且具有更高的效率、可扩展性和成本效率。
图7示出了示出了根据本公开的某些实施例的示例方法700的流程图。方法700可以在如图2所示的SRS 235处实施。为了讨论方便,以下参考图2对方法700进行具体描述。
如图所示,在框705,从网络设备225接收针对服务的请求,请求包括服务的标识。在框710,基于至少服务的标识和服务的至少一个实例215的至少一个访问地址之间的关联,从至少一个访问地址中确定供网络设备225访问的访问地址。在框715,向网络设备225发送所确定的访问地址。
在某些实施例中,关联包括服务的标识、至少一个实例215的访问地址以及至少一个实例215的属性之间的关联。
在某些实施例中,在确定访问地址时,可以首先确定与服务的标识相关联的至少一个实例215。继而,基于实例215的属性,选择供网络设备225访问的实例215,并且将所选择的实例215的访问地址确定为供网络设备225访问的访问地址。
在某些实施例中,至少一个实例215在至少一个SDN控制器210上运行,并且实例215的访问地址包括SDN控制器210的路由地址。
在某些实施例中,可以从至少一个SDN控制器210接收SDN控制器210的路由地址(例如,IP地址)及其所支持的至少一个服务的标识。继而,建立至少SDN控制器210的路由地址与至少一个服务的标识之间的关联。
在某些实施例中,关联包括至少一个SDN控制器210的路由地址、SDN控制器210所支持的至少一个服务的标识以及在SDN控制器210上运行的服务的实例215的属性之间的关联。在这些实施例中,建立关联时,还可以从SDN控制器210接收服务的实例215的属性,并且建立SDN控制器210的路由地址、服务的标识以及服务的实例215的属性之间的关联。
在某些实施例中,可以获得至少一个SDN控制器210所支持的至少一个服务的更新信息,并且基于该更新信息来更新所建立的关联。
应理解,上文结合图2-6描述的SRS 235所执行的操作和特征同样适用于方法700,并且具有同样的效果,具体细节不再赘述。
在某些实施例中,能够执行方法700的装置(例如,图2中所示的SRS 235)可以包括用于执行方法700的各个步骤的相应部件。这些部件可以任意适当方式实现。例如,可以通过电路或者软件模块来实现。
在某些实施例中,装置包括:用于从网络设备接收针对服务的请求的部件,请求包括服务的标识;用于基于至少服务的标识和服务的至少一个实例的至少一个访问地址之间的关联,从至少一个访问地址中确定供网络设备访问的访问地址的部件;以及用于向网络设备发送所确定的访问地址的部件。
在某些实施例中,关联包括服务的标识、至少一个实例的访问地址以及至少一个实例的属性之间的关联。
在某些实施例中,用于确定访问地址的部件可以包括:用于确定与服务的标识相关联的至少一个实例的部件;用于基于至少一个实例的属性,从至少一个实例中选择供网络设备访问的实例的部件;以及用于将所选择的实例的访问地址确定为供网络设备访问的访问地址的部件。
在某些实施例中,至少一个实例在至少一个SDN控制器上运行,并且至少一个实例的访问地址包括至少一个SDN控制器的路由地址。
在某些实施例中,装置还可以包括:用于从至少一个SDN控制器接收至少一个SDN控制器的路由地址以及至少一个SDN控制器所支持的至少一个服务的标识的部件;以及用于建立至少至少一个SDN控制器的路由地址与至少一个服务的标识之间的关联的部件。
在某些实施例中,关联包括至少一个SDN控制器的路由地址、至少一个服务的标识以及在至少一个SDN控制器上运行的至少一个服务的实例的属性之间的关联。用于建立关联的部件可以包括:用于从至少一个SDN控制器接收至少一个服务的实例的属性的部件;以及用于建立至少一个SDN控制器的路由地址、至少一个服务的标识以及至少一个服务的实例的属性之间的关联的部件。
在某些实施例中,装置还可以包括:用于获得至少一个SDN控制器所支持的至少一个服务的更新信息的部件;以及用于基于更新信息来更新所建立的关联的部件。
图8示出了适合实现本公开的实施例的设备800的方框图。设备800可以实施在图2所示的SRS 235处或者SRS 235的一部分。
如图8所示,设备800包括处理器810。处理器810控制设备800的操作和功能。例如,在某些实施例中,处理器810可以借助于与其耦合的存储器820中所存储的指令830来执行各种操作。存储器820可以是适用于本地技术环境的任何合适的类型,并且可以利用任何合适的数据存储技术来实现,包括但不限于基于半导体的存储器件、磁存储器件和系统、光存储器件和系统。尽管图8中仅仅示出了一个存储器单元,但是在设备800中可以有多个物理不同的存储器单元。
处理器810可以是适用于本地技术环境的任何合适的类型,并且可以包括但不限于通用计算机、专用计算机、微控制器、数字信号控制器(DSP)以及基于控制器的多核控制器模型中的一个或多个。设备800也可以包括多个处理器810。设备800可以包括通信模块(未示出),其借助于光纤或电缆等以有线方式或者可以无线方式来实现信息的接收和发送。
处理器810通过执行指令而使得设备800执行上文参考图2至图7描述的SRS 235的相关操作和特征。上文参考图2至图7所描述的所有特征均适用于设备800,在此不再赘述。
一般而言,本公开的各种示例实施例可以在硬件或专用电路、软件、逻辑,或其任何组合中实施。某些方面可以在硬件中实施,而其他方面可以在可以由控制器、微处理器或其他计算设备执行的固件或软件中实施。当本公开的实施例的各方面被图示或描述为框图、流程图或使用某些其他图形表示时,将理解此处描述的方框、装置、系统、技术或方法可以作为非限制性的示例在硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备,或其某些组合中实施。
作为示例,本公开的实施例可以在机器可执行指令的上下文中被描述,机器可执行指令诸如包括在目标的真实或者虚拟处理器上的器件中执行的程序模块中。一般而言,程序模块包括例程、程序、库、对象、类、组件、数据结构等,其执行特定的任务或者实现特定的抽象数据结构。在各实施例中,程序模块的功能可以在所描述的程序模块之间合并或者分割。用于程序模块的机器可执行指令可以在本地或者分布式设备内执行。在分布式设备中,程序模块可以位于本地和远端存储介质二者中。
用于实现本公开的方法的计算机程序代码可以用一种或多种编程语言编写。这些计算机程序代码可以提供给通用计算机、专用计算机或其他可编程的数据处理装置的处理器,使得程序代码在被计算机或其他可编程的数据处理装置执行的时候,引起在流程图和/或框图中规定的功能/操作被实施。程序代码可以完全在计算机上、部分在计算机上、作为独立的软件包、部分在计算机上且部分在远端计算机上或完全在远端计算机或服务器上执行。
在本公开的上下文中,计算机程序代码或者相关数据可以由任意适当载体承载,以使得设备、装置或者处理器能够执行上文描述的各种处理和操作。载体的示例包括信号、计算机可读介质、等等。
信号的示例可以包括电、光、无线电、声音或其它形式的传播信号,诸如载波、红外信号等。
计算机可读介质可以是包含或存储用于或有关于指令执行系统、装置或设备的程序的任何有形介质。计算机可读介质可以是计算机可读信号介质或计算机可读存储介质。计算机可读介质可以包括但不限于电子的、磁的、光学的、电磁的、红外的或半导体系统、装置或设备,或其任意合适的组合。计算机可读存储介质的更详细示例包括带有一根或多根导线的电气连接、便携式计算机磁盘、硬盘、随机存储存取器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或闪存)、光存储设备、磁存储设备,或其任意合适的组合。
另外,尽管操作以特定顺序被描绘,但这并不应该理解为要求此类操作以示出的特定顺序或以相继顺序完成,或者执行所有图示的操作以获取期望结果。在某些情况下,多任务或并行处理会是有益的。同样地,尽管上述讨论包含了某些特定的实施细节,但这并不应解释为限制任何发明或权利要求的范围,而应解释为对可以针对特定发明的特定实施例的描述。本说明书中在分开的实施例的上下文中描述的某些特征也可以整合实施在单个实施例中。反之,在单个实施例的上下文中描述的各种特征也可以分离地在多个实施例或在任意合适的子组合中实施。
尽管已经以特定于结构特征和/或方法动作的语言描述了主题,但是应当理解,所附权利要求中限定的主题并不限于上文描述的特定特征或动作。相反,上文描述的特定特征和动作是作为实现权利要求的示例形式而被公开的。