CN112655185B

CN112655185B - Apparatus, method and storage medium for service allocation in a software defined network

Info

Publication number: CN112655185B
Application number: CN201880097317.8A
Authority: CN
Inventors: 吕小鹏; 万永根
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2018-09-17
Filing date: 2018-09-17
Publication date: 2024-03-19
Anticipated expiration: 2038-09-17
Also published as: EP3855708A1; CN112655185A; EP3855708A4; WO2020056550A1

Abstract

Apparatus, methods, and computer-readable storage media for service allocation in a Software Defined Network (SDN) network. For example, in the method, a request for a service is received from a network device, the request including an identification of the service. An access address for access by the network device is determined from the at least one access address based on an association between at least an identification of the service and the at least one access address of the at least one instance of the service. The determined access address is then sent to the network device. This service-based SDN cluster management approach is more flexible and efficient.

Description

Apparatus, method and storage medium for service allocation in a software defined network

Technical Field

Embodiments of the present disclosure relate generally to communication technology and, more particularly, relate to an apparatus, method, and computer-readable storage medium for service allocation in a Software Defined Network (SDN) network.

Background

Network Function Virtualization (NFV) technology and Software Defined Network (SDN) technology have been applied in telecommunications networks. With NFV and SDN technologies, various network control functions may be provided, such as Open Shortest Path First (OSPF), internet Group Management Protocol (IGMP), path Computation Engine (PCE), topology computation and access control firewalls, etc., as well as various "Over The Top" (OTT) applications, such as data analysis and Artificial Intelligence (AI), etc. These functions or applications may be separate from the network data plane and deployed centrally in the SDN controller.

In managing large-scale networks, there may be some potential problems with using a single centralized SDN controller, such as performance bottlenecks due to processing power, latency overhead of communications between SDN controllers and switches, single point failure of SDN controllers, and security vulnerabilities for hacking, among others. In order to improve reliability and scalability, a plurality of SDN controllers may be grouped into an SDN controller cluster. SDN controllers within the cluster cooperate to manage underlying SDN switches using distributed controller technology.

In order for an SDN controller cluster to function properly, multiple techniques such as data consistency, load balancing, and virtual IP conversion/redirection are required to be integrated together, and multiple SDN controllers are required to cooperate with each other. This makes the system too complex to deploy and maintain.

Disclosure of Invention

In general, embodiments of the present disclosure propose an apparatus, a method and a computer readable storage medium for service allocation in an SDN network.

In a first aspect, embodiments of the present disclosure provide an apparatus in an SDN network. The apparatus includes at least one processor and at least one memory storing computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to receive a request for a service from a network device, including an identification of the service. The device is further caused to determine an access address for access by the network device from the at least one access address based on an association between at least the identification of the service and the at least one access address of the at least one instance of the service; and transmitting the determined access address to the network device.

In a second aspect, embodiments of the present disclosure provide a method in an SDN network. In the method, a request for a service is received from a network device, the request including an identification of the service. An access address for access by the network device is determined from the at least one access address based on an association between at least an identification of the service and the at least one access address of the at least one instance of the service. The determined access address is then sent to the network device.

In a third aspect, embodiments of the present disclosure provide a computer-readable storage medium comprising computer program instructions stored thereon. The instructions, when executed by a processor on a device, cause the device to perform the method according to the second aspect.

It should be understood that the description in this summary is not intended to limit key or critical features of the disclosed embodiments, nor is it intended to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

Several example embodiments will be described below in conjunction with the accompanying drawings, in which:

fig. 1 illustrates an example architecture of an SDN network for constructing a cluster based on SDN controller hosts;

fig. 2 illustrates an example architecture of an SDN network in accordance with certain embodiments of the present disclosure;

FIG. 3 illustrates an example process of service registration and monitoring by a Service Resolution System (SRS) in accordance with certain embodiments of the present disclosure;

FIG. 4 illustrates an example process of a network device invoking a service in accordance with certain embodiments of the present disclosure;

fig. 5 illustrates differences in cluster management between a service-based cluster and a conventional SDN controller host-based cluster in accordance with an embodiment of the present disclosure;

fig. 6 illustrates an example deployment of services on an SDN controller according to certain embodiments of the present disclosure;

FIG. 7 illustrates a flow chart of a method according to certain other embodiments of the present disclosure; and

fig. 8 illustrates a block diagram of a device suitable for implementing embodiments of the present disclosure.

In the drawings, the same or similar reference numerals denote the same or similar elements.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been shown in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.

The term "service" as used herein refers to any suitable control function or application provided in an SDN network. Examples of services include, but are not limited to, open Shortest Path First (OSPF), internet Group Management Protocol (IGMP), path Computation Engine (PCE), topology computation and access control firewalls, data analysis, artificial Intelligence (AI), and the like.

The term "SDN controller" as used herein refers to any suitable device capable of providing services in an SDN network. Examples of SDN controllers include, but are not limited to, one or more of the following: hosts, blade servers, personal Computers (PCs), routers, switches, laptops, tablet computers, and the like.

The term "network device" as used herein refers to any suitable device in an SDN network capable of accessing services, such as an SDN switch or other network entity.

The term "circuitry" as used herein refers to one or more of the following:

(a) Hardware-only circuit implementations (such as analog-only and/or digital-circuit implementations); and

(b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of analog and/or digital hardware circuitry and software/firmware, and (ii) any portion of a hardware processor and software (including digital signal processors, software, and memory that work together to cause an apparatus, such as an OLT or other computing device, to perform various functions); and

(c) Hardware circuitry and/or a processor, such as a microprocessor or a portion of a microprocessor, that requires software (e.g., firmware) for operation, but may not have software when software is not required for operation.

The definition of circuit applies to all scenarios in which this term is used in this application, including in any claims. As another example, the term "circuitry" as used herein also covers an implementation of only a hardware circuit or processor (or multiple processors), or a portion of a hardware circuit or processor, or its accompanying software or firmware. For example, if applicable to the particular claim element, the term "circuitry" also covers a baseband integrated circuit or processor integrated circuit or similar integrated circuit in an OLT or other computing device.

The term "including" and variations thereof as used herein are intended to be open-ended, i.e., including, but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment". Related definitions of other terms will be given in the description below.

As described above, in SDN network management, to improve network management performance of a single SDN controller and to improve reliability and scalability, multiple SDN controllers may interoperate as an SDN controller cluster to manage underlying SDN switches using distributed controller technology. SDN controller clusters have dynamics due to service disruption of cluster members or joining of new members. Load balancing or other policy requirements for network optimization may also lead to the dynamics of SDN controller clusters.

In order for an SDN controller cluster to function properly, on the one hand, multiple distributed SDN controllers should cooperate to maintain data and state consistency among SDN controllers, and to dynamically manage joining/leaving of members in the SDN controller cluster, etc. On the other hand, the SDN controller cluster needs to manage load balancing of the distributed SDN controllers, so as to allocate appropriate SDN controllers to communicate with and manage the underlying SDN switches in the dynamic environment.

Therefore, management of SDN controller clusters is very important in several aspects: effectively manage dynamic joining/leaving of members in an SDN controller cluster, maintain data/state consistency throughout the cluster, and dynamically allocate appropriate SDN controllers to manage underlying SDN switches based on processing power (e.g., load state) or geographic location (for delay optimization) among other policies.

Fig. 1 shows an example architecture of an SDN network 100 that builds clusters based on SDN controller hosts. In network 100, cluster 105 is comprised of a plurality of SDN controllers 110-1, 110-2 … … 110-N (collectively, "SDN controllers 110"). A manager (e.g., zookeeper) 115 interacts with SDN controller 110 to monitor it. The manager 115 may also interact with the load balancer 120 to dynamically allocate appropriate SDN controllers to manage underlying network devices (e.g., SDN switches) 125-1, 125-2 … … -125-M according to processing power (e.g., load status) or other policies. To maintain data consistency within clusters 105, SDN controllers 110 have east-west interface connections 130-1 … … -K (collectively "interface connections 130") between them for communication and synchronization between SDN controllers 110. N, M and K are any suitable positive integers.

In addition to data synchronization via the interface connection 130, there is also a data-centric approach. The method adopts a data and logic separated architecture, and uses a shared data repository to save the state and operation data of the SDN controller 110, so that the consistency of the data is ensured under the condition of switching of the SDN controller 110.

In network 100, manager 115 may manage the joining and leaving of SDN controllers 110 in cluster 105. For example, manager 115 may monitor "znides" in its data structure (e.g., a Zookeeper node or "znides" list) created by SDN controller 110. If a certain SDN controller 110 comes out of service, the corresponding "znode" will be deleted from the monitored list of "znode" and thus trigger the relevant cluster management operation.

To dynamically allocate the appropriate SDN controller 110 to manage the underlying network devices 125 according to an optimization strategy such as load balancing, as shown in fig. 1, the load balancer 120 is responsible for distributing requests of network devices 125 to the appropriate SDN controllers 110. In network 100, the virtual Internet Protocol (IP) address of load balancer 120 is published to network device 125. When the network device 125 accesses the virtual IP address, communications from the network device 125 will be translated and redirected to the actual IP address of the SDN controller 110 in the cluster 105. Traditionally, load balancing is based on SDN controller hosts. The load balancing algorithm may employ a polling algorithm or a Hash (Hash) algorithm, etc.

The cluster management approach based on the manager 115 (e.g., zookeeper) shown in fig. 1 requires that multiple techniques of data consistency, load balancing, and virtual IP translation and redirection are integrated together and cooperate with each other. Moreover, the load balancer 120 requires high traffic processing capability to avoid becoming a traffic bottleneck. This makes the system too complex to deploy and maintain.

The inventors note that such clusters established based on SDN controller hosts require that each SDN controller is identical, i.e. the capabilities are identical, as are the services. However, each SDN controller may not actually be identical in terms of processing power, storage power, network bandwidth, and the like.

The inventors have also noted that the provision of services and data is the nature of the network interconnection, with host-centric connections being merely an intermediary to the network interconnection for providing services and data. Providing different services in different SDN controllers would add great flexibility to the configuration of SDN controller 110. Moreover, the services are basic control functions in the SDN controller that manage the underlying network devices. In practical applications, particularly for NFV, cloud, and microservice development, functions or services are often fundamental granularity of warnings or faults that require optimization or correction. Thus, there is a need to establish clusters of service levels that can manage the joining or leaving of service levels.

The embodiment of the disclosure provides a service-oriented SDN cluster management mechanism. The mechanism forms an SDN service cluster instead of an SDN controller host cluster with a service center. This service-centric mechanism introduces a Service Resolution System (SRS). The SRS maintains an association between at least an identification of a service in the SDN network and access addresses of various instances of the service (e.g., running on an SDN controller). Upon receiving a request for a service from a network device, based on the association, the SRS parses the service request from the network device into access addresses for the corresponding service instances. Thus, the network device can use the access address to access the corresponding service.

According to embodiments of the present disclosure, SDN controllers may cooperate at a service level and may dynamically allocate services for managing underlying network devices (e.g., SDN switches) at the service level based on policies such as load balancing and geographic location optimization. In this way, more accurate management of SDN controllers and allocation of services provided by SDN controllers to underlying network devices may be achieved.

For example, the SRS may perform service resolution and determine policies such as service load balancing and location optimization to find a route locator of a service for an underlying network device, e.g., an access address (e.g., IP address) of an SDN controller capable of providing the service. The SRS may also dynamically maintain an association between service identities and access addresses (i.e., locations where services are located) of service instances running on the SDN controller, dynamically manage service joining and leaving in the service cluster, monitor service load conditions in real-time, and so on.

In such SDN service clusters, services required by underlying network devices may be routed through identification of the services and based on service load conditions and/or other additional routing policies such as geographic location optimization or customer categories. Services and their identification are fundamental factors for routing. Service-level joining or leaving may be managed in a cluster, service-granularity load balancing may be managed, and communication between an associated SDN controller and a network device may be managed according to services invoked by the network device. In addition, the SDN controller may optionally install services as a container for the services, and these services may be the same or different. Such a service cluster is more flexible.

Fig. 2 illustrates an example architecture of an SDN network 200 in accordance with certain embodiments of the present disclosure. The network 200 includes a plurality of SDN controllers 210-1, 210-2 … … 210-N (collectively SDN controllers 210). One or more service instances 215-1, 215-2, … … -L (collectively "service instances 215") run on each SDN controller 210. The service instance 215 may be accessed or invoked by the underlying network devices 225-1, 225-2 … … 225-L (collectively, "network devices 225") in the network 200. N, M and L are any suitable positive integers.

With support of virtualization and cloud technology, service instances 215 may be virtualized and may run in different virtual machines in SDN controller 210. Each service instance 215 in SDN controller 210 may have a respective alarm, fault and load status, etc.

Due to the different configurations of SDN controllers 210 and dynamic changes of service instances 215 on each SDN controller 210, SDN controllers 210 may not provide exactly the same services. Service instances 215 on different SDN controls 210 may perform the same or different functions or applications.

In the example shown in fig. 2, service instance 215-1 running on SDN controller 210-1, service instance 215-4 running on SDN controller 210-2, and service instance 215-6 running on SDN controller 210-3 perform the same function. Service instance 215-2 running on SDN controller 210-1 performs the same function as service instance 215-5 running on SDN controller 210-2. Service instance 215-3 running on SDN controller 210-1 performs the same function as service instance 215-L running on SDN controller 210-N. As such, the deployment and service configuration of SDN controller 210 has great flexibility. Each SDN controller 210 need not provide exactly the same services nor need it have very high capacity.

In network 200, each service and its instance 215 has a corresponding identity. The identification may be unique within the network 200. For example, different instances of the same service have the same service identity and instances of different services have different service identities. In the example shown in FIG. 2, service instances 215-1, 215-4, and 215-6 have service identification A. Service instances 215-2 and 215-5 have service identity B and service instances 215-3 and 215-L have service identity C. Services may be named using any suitable naming scheme, both currently known and developed in the future. As an example, to ensure identity and service integrity, a hashing algorithm based on a service-based software image may be used to generate the unique identity.

In network 200, service data and logical separation architecture and shared data stores are used to maintain data consistency between services. For example, as shown in FIG. 2, a data store 230 is included in the network 200. The data repository 230, which is a shared data repository, may interact with the SDN controller 210 for storing information such as state and operation data of service instances running on the SDN controller 210. The use of the data store 230 enables service instances 215 in each SDN controller 210 to be stateless, thereby maintaining consistency of service related information in a dynamic environment, such as at service switching.

It should be appreciated that the data store 230 is shown in FIG. 2 for purposes of example only and not limitation. In some embodiments, rather than employing such a data and logic separated architecture, SDN controllers 210 may interact service state and operational data, etc., through interfaces between each other (e.g., interface connection 130 in fig. 1) to maintain data consistency.

Network 200 also includes a Service Resolution System (SRS) 235. The SRS 235 is responsible for service resolution for determining an access address for a service for the network device 225 requesting the service. In embodiments of the present disclosure, SRS 235 maintains an association between at least an identification of a service and an access address of each instance 215 of the service (e.g., an IP address or other routing locator of SDN controller 210 running the respective instance 215).

In some embodiments, SRS 235 may also select service instance 215 for access by network device 225 in consideration of predefined policies such as load balancing and location optimization. In this case, SRS 235 may bind the state or attribute of service instance 215 with the service identification and the access address of service instance 215. Thus, selection of service instances may be made based on predefined policies, thereby providing greater scalability for policy management and policy-based service selection.

For example, SRS 235 may maintain an association between an identification of a service, access addresses of individual instances 215 of the service, and attributes (e.g., load conditions) of the service instances 215. As such, SRS 235 can employ a service load balancing related policy algorithm to find the most appropriate service instance. The association may be stored in a table form, either locally to SRS 235 or in an external storage device (not shown) accessible to SRS 235.

In certain embodiments, as shown in fig. 2, SRS 235 establishes the association by interacting (240) with SDN controller 210. For example, SRS 235 may receive a routing address (e.g., IP address) of SDN controller 210 and an identification of services supported by SDN controller 210 from SDN controller 210, and then establish an association between the routing address and the service identification. If SRS 235 may also receive attributes (e.g., load conditions) of a service instance running on SDN controller 210 from SDN controller 210, SRS 235 may establish an association between a routing address of SDN controller 210, an identification of the service, and attributes of the service instance.

In some embodiments, SRS 235 may update the established association. For example, when a new service is activated at SDN controller 210, or a service fails or stops, SRS 235 may obtain relevant information from SDN controller 210 and update the association based on the information. For example, SRS 235 may register for a newly activated service or deregister a stopped service.

Fig. 3 illustrates an example process 300 for service registration and monitoring by SRS 235 according to some embodiments of the present disclosure. Process 300 includes two processes, service registration and service monitoring. The service registration process may be performed during an activation phase of SDN controller 210. For example, SDN controller 210-1 may register (305) its own IP address X and identities A, B and C of supported services with SRS 235 upon activation. SDN controller 210-2 may register 310 IP address Y with SRS 235 and service identities a and B. SDN controller 210-N may register 315 IP address Z with SRS 235 and service identities a and C. At block 320, srs 235 establishes an association between each IP address X, Y and Z and service identities A, B and C.

The service monitoring phase may be performed during an operation phase of the SDN controller 210 for monitoring a state of a corresponding service instance 215 running on the SDN controller 210, e.g. whether a new service instance is activated; or monitor a property of the service instance 215, such as whether a certain existing service instance has failed. The service monitoring may be performed by a heartbeat mechanism. For example, when SDN controller 210 is in an operational phase, SDN controller 210 may periodically (every second) update its service state (e.g., service joining or leaving) and service attributes (e.g., service loading conditions) by interacting with heartbeats of SRS 235.

As shown in fig. 3, SDN controller 210-1 updates (325) the state and load of service instances 215-1, 215-2, and 215-3 with heartbeat interactions. SDN controller 210-2 updates (330) the state and load of service instances 215-4 and 215-5 with heartbeat interactions. SDN controller 210-N updates (335) the state and load of service instances 215-6 and 215-L with heartbeat interactions. 325. 330 and 335 may be performed in loops (340). At block 345, srs 235 may add the load of each service instance 215 running on SDN controller 210 to the established association.

The association may be recorded in table 1 below.

TABLE 1

The association of service identities A, B and C, IP addresses X, Y and Z and the load conditions (expressed in percent) of the corresponding service instance 215 is stored in table 1.

When a new service joins (e.g., adds or activates) or an existing service leaves (e.g., deactivates or fails), the updated service state will trigger a change in the corresponding association in SRS 235. For example, when a service instance 215 on SDN controller 210 is deactivated or fails, the service instance 215 will be de-registered by SRS 235. As shown in fig. 3, at block 350, the srs 235 may deregister the corresponding service instance 215 upon failure of a certain heartbeat interaction. Changes in service load conditions can be reflected in the established associations in real time by frequently updating the load conditions of the service instances 215.

For example, when service instance 215-2 running on SDN controller 210-1 fails, table 1 may be updated to table 2 as follows.

TABLE 2

IP address	Service identification	Service load
			X	A	80％
X	B	20％
			X	C	70％
Y	A	90％
			Z	A	20％
Z	C	30％

In table 2, the entry associated with IP address Y and service identification B is deleted.

With continued reference now to fig. 2, SRS 235 receives (245) a service request from network device 225 that includes a service identification (e.g., identification a) in accordance with an embodiment of the present disclosure. Based on the association between the service identification and the access address of the relevant service instance 215, the SRS 235 selects an access address for access by the network device 225. For example, in the case where service identification A is included in the service request from the network device, SRS 235 can select the access address of service instance 215-6 based on the association between service identification A and the access addresses of service instances 215-1, 215-4, and 215-6. In turn, SRS 235 transmits (250) the selected access address to network device 225. Using the access address, the network device 225 may interact (255) with a respective SDN controller 210 (e.g., SDN controller 210-N) to access or invoke a respective service instance 215 (e.g., service instance 215-6).

Fig. 4 illustrates an example process 400 for a network device 225 to invoke a service in accordance with certain embodiments of the present disclosure. As shown in fig. 4, network device 225-1 prepares to invoke a service identified as a at block 405. At 410, network device 225-1 sends a service resolution request to SRS 235, which includes service identification A. At block 415, srs 235 performs service resolution. For example, by looking up a table that records associations between service identities and access addresses of service instances and load cases of service instances, it is determined that service instances 215-6 on SDN controller 210-N are available to network device 225-1 and identity a is resolved to IP address Z. At 420, SRS 235 transmits a service resolution response to network device 225-1, which includes address Z. Based on the address Z, the network device 225-1 performs Openflow communication with the SDN controller 210-N at 425. Any suitable Openflow communication technique currently known and developed in the future may be employed. The scope of the present disclosure is not limited in this respect. At block 430, sdn controller 210-N invokes service instance 215-6 corresponding to identification a.

Next, at block 435, the network device 225-2 prepares to invoke the service identified as C. At 440, network device 225-2 sends a service resolution request to SRS 235, which includes service identification C. At block 445, srs 235 performs service resolution. At 450, SRS 235 transmits a service resolution response to network device 225-1, which includes address Z. Based on the address Z, the network device 225-2 communicates Openflow with the SDN controller 210-N at 455. At block 460, SDN controller 210-N invokes service instance 215-L corresponding to identification C.

For a network device 225 (e.g., an SDN switch), the requested service is independent of location (e.g., an SDN controller 210 that provides the service). Network device 225 need not be concerned with the specific location of the service, but need only request the service from SRS 235 via the service identification. Upon obtaining the service location from SRS 235, network device 225 may perform conventional communications (e.g., openflow communications) with target SDN controller 210 to access or invoke the corresponding service.

Based on NFV and cloud development for provisioning of services, embodiments of the present invention center services as new network architecture and scale traditional SDN controller host-based clusters to service-based clusters. In service-based clusters, service failover and service plug-and-play will be performed in more accurate and efficient parties. Such service-based clusters are more advantageous in terms of cluster management.

Fig. 5 illustrates the differences in cluster management between a service-based cluster and a conventional SDN controller host-based cluster in accordance with an embodiment of the present disclosure. As shown in fig. 5, in an SDN controller host-based cluster 505, failure of a certain service instance 215-7, 215-8 or 215-9 on an SDN controller 210-3 will result in failure of the entire SDN controller 210-3, i.e. all services in the SDN controller 210-3 will stop.

In service-based cluster 510, if a service instance 215-7 running on SDN controller 210-3 fails, only that service instance 215-7 stops running, while other service instances 215-8 and 215-9 are unaffected and may continue to serve underlying network device 225. This more accurate management mechanism enhances redundancy and protection capabilities of the SDN clusters while minimizing impact on cluster processing capabilities or probability of the SDN controller 210 shutting down.

In such a service-centric architecture, service provisioning is independent of the SDN controller, so that flexibility in service configuration and SDN controller deployment may be provided in a dynamic service cluster environment without deploying exactly the same service in the SDN controller. In practice, flexible and different service deployments in SDN controllers are required due to several considerations, such as:

-different processing capabilities of SDN controllers

Different delay sensitivities of the service to geographic position

Different load demands of services

Different security protection levels of services

Cost optimization of clusters

Fig. 6 illustrates an example deployment of services on an SDN controller according to certain embodiments of the present disclosure. In this example, cluster 605 includes three SDN controllers 210-1, 210-2, and 210-N with IP addresses X, Y, and Z, respectively. Assume that three SDN controllers 210-1, 210-2, and 210-N have different processing capabilities, different geographic proximity, and different costs, as shown in table 3 below.

TABLE 3 Table 3

SDN controller IP address	Processing capacity	Geographic proximity	Cost of
				X	High height	Good (good)	100％
Y	In (a)	Good (good)	70％
				Z	Low and low	Difference of difference	40％

Services such as IGMP, access control, and data analysis may be provided in cluster 605. Each service has different requirements for load, delay and security as shown in table 4 below.

TABLE 4 Table 4

Service	Delay sensitivity	Security level	Service load
				IGMP	High height	Low and low	In (a)
IGMP	Low and low	In (a)	Low and low
				Access control	Low and low	Low and low	In (a)
Data analysis	Low and low	Low and low	Low and low

As shown in fig. 6, to meet the requirements of delay-sensitive IGMP, such as fast handoff, IGMP services may be deployed in SDN controllers 210-1 and 210-N (e.g., service instances 215-10 and 215-17) because of their good geographic proximity. To balance the high service load of the data analysis service, SDN controllers 210-1, 210-2, and 210-N will install service instances 215-12, 215-15, and 215-18 for the service. Moreover, access control services will also be deployed to all three SDN controllers 210-1, 210-2, and 210-N (e.g., service instances 215-13, 215-16, and 215-19) to provide better redundancy to prevent service failure or hacking. Because the PCE service has low requirements on load, security, and latency, instances 215-11 and 215-14 of the service may be deployed only in SDN controllers 210-1 and 210-2. The overall cost of SDN controllers in service-based cluster 605 is optimized, reducing from 300 to 210, by 30% compared to an SDN controller host-based cluster (three identical high-cost SDN controllers are required to deploy all of these services).

Compared to complex multi-technology integration, SRS provides a simple solution for cluster management and service resolution through simple binding of service identification and service location. Moreover, since no traffic passes through SRS, potential performance bottlenecks in the load balancing solution are avoided. Further, policies such as load status, etc., traditionally used to select and assign SDN controller hosts for underlying network devices (e.g., SDN switches) will become more accurate as cluster management transitions to service level, allowing finer policy management and enforcement. For example, according to a traditional SDN controller host-based policy, when the total load of a certain SDN controller is too high, the SDN controller host will not accept new tasks. However, if a service level policy is adopted, the low-load service in the SDN controller host may still accept new tasks. This maximizes the processing power of the SDN controller. Moreover, the SRS may add further attributes in the established association, such as service load, client category, and geographic location, etc. Accordingly, the SRS can be easily extended to cope with various new strategies, thereby achieving more complex and accurate service selection. Service-based clusters according to embodiments of the present disclosure are simpler and more efficient, scalable, and cost-effective than traditional SDN controller-host based clusters.

Fig. 7 illustrates a flow chart showing an example method 700 according to some embodiments of the disclosure. Method 700 may be implemented at SRS 235 as shown in fig. 2. For ease of discussion, method 700 is described in detail below with reference to FIG. 2.

As shown, at block 705, a request for a service is received from a network device 225, the request including an identification of the service. At block 710, an access address for access by the network device 225 is determined from the at least one access address based on an association between at least an identification of the service and the at least one access address of the at least one instance of the service 215. At block 715, the determined access address is sent to the network device 225.

In some embodiments, the association includes an association between an identification of the service, an access address of the at least one instance 215, and an attribute of the at least one instance 215.

In some embodiments, upon determining the access address, at least one instance 215 associated with the identification of the service may be first determined. Then, based on the attributes of instance 215, an instance 215 is selected for access by network device 225, and the access address of the selected instance 215 is determined as the access address for access by network device 225.

In certain embodiments, at least one instance 215 runs on at least one SDN controller 210, and the access address of instance 215 comprises a routing address of SDN controller 210.

In certain embodiments, an identification of a routing address (e.g., IP address) of SDN controller 210 and at least one service supported thereby may be received from at least one SDN controller 210. In turn, an association is established between at least a routing address of the SDN controller 210 and an identity of at least one service.

In certain embodiments, the association includes an association between a routing address of at least one SDN controller 210, an identification of at least one service supported by SDN controller 210, and an attribute of an instance 215 of a service running on SDN controller 210. In these embodiments, when establishing the association, attributes of instances 215 of the service may also be received from SDN controller 210 and an association between the routing address of SDN controller 210, the identity of the service, and the attributes of instances 215 of the service is established.

In certain embodiments, update information for at least one service supported by at least one SDN controller 210 may be obtained and the established association updated based on the update information.

It should be appreciated that the operations and features performed by SRS 235 described above in connection with fig. 2-6 are equally applicable to method 700 and have the same effect and specific details are not repeated.

In certain embodiments, an apparatus capable of performing method 700 (e.g., SRS 235 shown in fig. 2) may include corresponding means for performing the various steps of method 700. These components may be implemented in any suitable manner. For example, it may be implemented by a circuit or a software module.

In certain embodiments, an apparatus comprises: means for receiving a request for a service from a network device, the request including an identification of the service; means for determining an access address for access by the network device from the at least one access address based on an association between at least an identification of the service and the at least one access address of the at least one instance of the service; and means for sending the determined access address to the network device.

In some embodiments, the association includes an association between an identification of the service, an access address of the at least one instance, and an attribute of the at least one instance.

In some embodiments, the means for determining the access address may comprise: means for determining at least one instance associated with an identification of a service; means for selecting an instance for access by the network device from the at least one instance based on the attributes of the at least one instance; and means for determining an access address of the selected instance as an access address for access by the network device.

In certain embodiments, at least one instance runs on at least one SDN controller and the access address of the at least one instance includes a routing address of the at least one SDN controller.

In some embodiments, the apparatus may further comprise: means for receiving from at least one SDN controller a routing address of the at least one SDN controller and an identification of at least one service supported by the at least one SDN controller; and means for establishing an association between the routing address of the at least one SDN controller and the identity of the at least one service.

In certain embodiments, the association comprises an association between a routing address of the at least one SDN controller, an identification of the at least one service, and an attribute of an instance of the at least one service running on the at least one SDN controller. The means for establishing an association may include: means for receiving attributes of an instance of at least one service from at least one SDN controller; and means for establishing an association between the routing address of the at least one SDN controller, the identity of the at least one service and the attributes of the instance of the at least one service.

In some embodiments, the apparatus may further comprise: means for obtaining update information for at least one service supported by at least one SDN controller; and means for updating the established association based on the update information.

Fig. 8 illustrates a block diagram of a device 800 suitable for implementing embodiments of the present disclosure. Device 800 can be implemented at SRS 235 or a portion of SRS 235 as shown in fig. 2.

As shown in fig. 8, the device 800 includes a processor 810. Processor 810 controls the operation and functions of device 800. For example, in some embodiments, the processor 810 may perform various operations by way of instructions 830 stored in a memory 820 coupled thereto. Memory 820 may be of any suitable type suitable to the local technical environment and may be implemented using any suitable data storage technology including, but not limited to, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems. Although only one memory unit is shown in fig. 8, there may be multiple physically distinct memory units in device 800.

The processor 810 may be of any suitable type suitable to the local technical environment and may include, but is not limited to, one or more of a general purpose computer, a special purpose computer, a microcontroller, a digital signal controller (DSP), and a controller-based multi-core controller model. The device 800 may also include a plurality of processors 810. The device 800 may comprise a communication module (not shown) enabling the reception and transmission of information by means of optical fibers or cables, etc., in a wired manner or in a wireless manner.

The processor 810, by executing the instructions, causes the device 800 to perform the related operations and features of the SRS 235 described above with reference to fig. 2-7. All of the features described above with reference to fig. 2-7 apply to the device 800 and are not repeated here.

In general, the various example embodiments of the disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While aspects of the embodiments of the present disclosure are illustrated or described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

By way of example, embodiments of the present disclosure may be described in the context of machine-executable instructions, such as program modules, being included in devices on a real or virtual processor of a target. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between described program modules. Machine-executable instructions for program modules may be executed within local or distributed devices. In a distributed device, program modules may be located in both local and remote memory storage media.

Computer program code for carrying out methods of the present disclosure may be written in one or more programming languages. These computer program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the computer or other programmable data processing apparatus, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the computer, partly on the computer, as a stand-alone software package, partly on the computer and partly on a remote computer or entirely on the remote computer or server.

In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable an apparatus, device, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, and the like.

Examples of signals may include electrical, optical, radio, acoustical or other form of propagated signals, such as carrier waves, infrared signals, etc.

A computer readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More detailed examples of a computer-readable storage medium include an electrical connection with one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical storage device, a magnetic storage device, or any suitable combination thereof.

In addition, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking or parallel processing may be beneficial. Likewise, although the foregoing discussion contains certain specific implementation details, this should not be construed as limiting the scope of any invention or claims, but rather as describing particular embodiments that may be directed to particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. An apparatus in a software defined network, SDN, comprising:

at least one processor, and

at least one memory storing computer program code,

the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

receiving a request for a service from a network device, the request including an identification of the service;

determining an access address for access by the network device from at least the at least one access address of at least the identification of the service and at least one access address of at least one instance of the service based on an association between the at least one access address and the at least one identification of the service; and

transmitting the determined access address to the network device,

wherein the at least one instance runs on at least one SDN controller and the access address of the at least one instance comprises a routing address of the at least one SDN controller.

2. The apparatus of claim 1, wherein the association comprises an association between the identification of the service, an access address of the at least one instance, and an attribute of the at least one instance.

3. A device according to claim 2, wherein the device is caused to determine the access address by:

Determining the at least one instance associated with the identification of the service;

selecting an instance for access by the network device from the at least one instance based on the attribute of the at least one instance; and

an access address of the selected instance is determined as the access address for access by the network device.

4. An apparatus of claim 1, wherein the apparatus is further caused to:

receiving, from the at least one SDN controller, a routing address of the at least one SDN controller and an identification of at least one service supported by the at least one SDN controller; and

an association is established between at least the routing address of the at least one SDN controller and the identification of the at least one service.

5. The apparatus of claim 4, wherein the association comprises an association between the routing address of the at least one SDN controller, the identification of the at least one service, and an attribute of an instance of the at least one service running on the at least one SDN controller, and the apparatus is caused to establish the association by:

receiving the attributes of the instance of the at least one service from the at least one SDN controller; and

The association between the routing address of the at least one SDN controller, the identification of the at least one service and the attribute of the instance of the at least one service is established.

6. An apparatus of claim 4 or 5, wherein the apparatus is further caused to:

obtaining updated information of the at least one service supported by the at least one SDN controller; and

the established association is updated based on the update information.

7. A method implemented in a software defined network, SDN, comprising:

transmitting the determined access address to the network device,

8. The method of claim 7, wherein the association comprises an association between the identification of the service, an access address of the at least one instance, and an attribute of the at least one instance.

9. The method of claim 8, wherein determining the access address comprises:

10. The method of claim 7, further comprising:

11. The method of claim 10, wherein the association comprises an association between the routing address of the at least one SDN controller, the identification of the at least one service, and an attribute of an instance of the at least one service running on the at least one SDN controller, and establishing the association comprises:

12. The method of claim 10 or 11, further comprising:

the established association is updated based on the update information.

13. An apparatus in a software defined network, SDN, comprising:

means for receiving a request for a service from a network device, the request including an identification of the service;

means for determining an access address for access by the network device from at least the at least one access address of at least one instance of the service based on an association between the identification of the service and the at least one access address; and

means for transmitting the determined access address to the network device,

14. A computer-readable storage medium comprising computer program instructions stored thereon, which when executed by a processor on a device, cause the device to perform actions comprising:

transmitting the determined access address to the network device,

15. The computer-readable storage medium of claim 14, wherein the association comprises an association between the identification of the service, an access address of the at least one instance, and an attribute of the at least one instance.

16. The computer-readable storage medium of claim 15, wherein determining the access address comprises:

17. The computer-readable storage medium of claim 14, wherein the acts further comprise:

18. The computer-readable storage medium of claim 17, wherein the association comprises an association between the routing address of the at least one SDN controller, the identification of the at least one service, and an attribute of an instance of the at least one service running on the at least one SDN controller, and establishing the association comprises:

19. The computer-readable storage medium of claim 17 or 18, wherein the acts further comprise:

the established association is updated based on the update information.