Network management with network virtualization based on modular quality of service control (MQC)

The present disclosure describes implementation of network virtualization based on modular quality of service control (MQC) in a data center network. In one example, a command originating from a tenant of a VDC is received by a network management server, the command being associated with network resource processing based on MQC. Based on a network resource configuration for the VDC, the received command is processed on a network virtualization layer of the network management server such that only processing associated with the VDC of the tenant is performed.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a 371 application of International Application No. PCT/CN2013/079761 filed on Jul. 22, 2013 and entitled “Network Management with Network Virtualization based on Modular Quality of Service Control (MQC),” which claims benefit of Chinese Patent App. No. CN 201210293340.9 filed on Aug. 17, 2012.

BACKGROUND

As user demand continues to grow, network virtualization techniques may be used to provide an abstraction between physical network resources and their virtual representation. Network virtualization allows tenants in a data center network to share physical network resources that are logically separated into different virtual data centers (VDCs). From the point of view of tenants, they appear to have access to a full network which can be managed and deployed through network management. For example, the tenant may independently manage topology discovery and configuration management of its VDC.

DETAILED DESCRIPTION

Although network resources are shared among tenants of different VDCs, the VDCs should be segregated from each other. For example, during network resource assignment, changes to one VDC should not affect another VDC. One way is to add a tenant's label to a message, such as using Virtual eXtensible Local Area Network (VXLAN) tags etc. A communications protocol called OpenFlow has also been developed.

The present disclosure describes implementation of network virtualization based on modular quality of service (QoS) control (MQC) in a data center network. In one example, a command originating from a tenant of a VDC is received by a network management server, the command being associated with network resource processing based on MQC. Based on a network resource configuration for the VDC, the received command is processed on a network virtualization layer of the network management server such that only processing associated with the VDC of the tenant is performed

According to the present disclosure, the network management server implements a network virtualization layer to facilitate segregation among VDCs. Since a received command is processed based on the network resource configuration for the VDC, only processing associated with the VDC of the tenant is performed. As such, each VDC may be controlled and managed independently and the tenant of a particular VDC can only see and manage resources of that VDC without affecting or being affected by other VDCs.

Unlike VxLAN and Openflow, the example according to the present disclosure is implemented by the network management server and does not require significant modifications of existing network devices in the data center network. For example, compared to Openflow, the present disclosure is easier and less costly to implement because it does not require significant changes to network switches to allow separation of forwarding plane and control plane and addition of a FlowVisor that sits logically between the forwarding and control paths on network switches.

Examples will be described with reference to accompanying drawings.

FIG. 1is a schematic diagram of an example data center network100with includes a network management server110and network devices120. The network devices120represent the physical network in the data center network100and may include switches etc. As illustrated inFIG. 1, the network devices120are abstracted or logically divided into different virtual networks or VDCs122accessible by different tenants130.

Tenants130(e.g. tenant administrators etc.) access the network devices120via the network management server110. From the perspective of the tenants130, they see what appears to be a full network (see also160) although the network management server110only allows them to access and manage their own VDC (see162). For example, tenants130within VDC1 can only access and manage network resources of VDC1, tenants130within VDCN can only access and manage network resources of VDCN etc.

Network devices120in a data center network100may perform various control functions based on MQC. Throughout the present disclosure, the term MQC refers generally to a Quality of Service (QoS) configuration approach where QoS service parameters are configured using a QoS policy. For instance, a QoS policy may be a set of class-behaviour associations. A traffic behaviour for a class may be defined using a set of QoS actions to perform on packets of that class, such as traffic filtering (e.g. permit or deny), shaping, policing and priority mapping etc. A class may be configured for any type of traffic, e.g. voice traffic; voice over Internet Protocol (VOIP) traffic; video traffic; signalling traffic; network protocol traffic; operations, administration and management (OAM) traffic; low-latency streaming traffic; high-throughput traffic; low priority traffic; high priority traffic, peer to peer traffic (P2P) etc. Traffic may also be divided into different classes based on information such as Internet Protocol address and layer 4-7 information to differentiate between File Transfer Protocol (FTP), Instant Messaging (IM), Email, and Bit Torrent (BT) traffic, etc.

A classifier may be used to perform the control functions, since it has a strong ability for identification of classes or flows based on matching rules. For example, flow identification may be based on Access Control List (ACL) number, Media Access Control (MAC), Real-time Transport Protocol (RTP) port, priority, ingress interface, discarded priority, VLAN ID, protocol type etc. Example classifiers include Remark, Firewall, Account, Redirect, Mirror, Wred, Wred Class, Queue, Car, GTS, etc.

In the example inFIG. 1, the network management server110may include the following:Tenant portals112(“first management module”) via which tenants130access functions of the network management server110. Different tenant portals112may be provided for different VDCs, such as ‘Tenant Portal A’ for VDC1, ‘Tenant Portal B’ for VDC2, and ‘Tenant Portal C’ for VDC3 etc.A network management virtualization layer114(“second management module”) to facilitate segregation among different VDCs to achieve network virtualization. In one example, network resource processing commands sent by a tenant130of a VDC may be processed by the network virtualization layer114such that only processing associated with the VDC of the tenant130is performed. This way, the tenant130can access its VDC exclusively without affecting, or being affected by, other tenants130.

The first management module112and second management module114may be independent from each other, and the first management module112may be unaware of the existence of the second management module114. In practice, the first management module112may be implemented using any suitable management software and the second management module114may serve as a management proxy (also referred to as “NetVisor”).

In practice, the first management module112may have limited functionality and is therefore used with the second management module114. Although the first management module112is implemented on the network management server110according toFIG. 3, it may also be implemented on a separate device on the tenant's side. In one example, the second management module114may be referred to as “Netvisor”.

Although multiple tenant portals112are shown inFIG. 1, it will be appreciated that they may be combined into a single portal for different VDCs. Further, althoughFIG. 1shows the first management module114on the network management server110inFIG. 1, it may be implemented on a different device, such as one on the tenant's side.

Each VDC is associated with a network resource configuration140(also referred to as “VDC configuration” inFIG. 1). In one example, network resource configuration140for each VDC may include information for flow-based differentiation, such as:Layer 2 (data link layer) information, such as Virtual Local Area Network (VLAN), source or destination MAC, link protocol (e.g. Address Resolution Protocol (ARP) and Reverse Address Resolution Protocol (RARP)), etc.Layer 3 (network layer) information, such as source or destination Internet Protocol (IP), IP/IPv6, IP protocol such as Transport Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP), etc.Layer 4 (transport layer) information, such as source or destination Layer-4 port, Type of Service (ToS) priority, Internet Protocol (IP) priority, differentiated services code point (DSCP), 802.1p priority, etc.

The network resource configuration140may be stored by the network management server110. Alternatively or additionally, the network resource configuration140for each VDC may be stored on a different device local to the network management server110or a remote one.

A data center administrator150also has access to the network resource configuration of various VDCs via any suitable network management software152. For example, the network management software152may be Intelligent Management Center (IMC) software. In general, full access to the network devices120is provided to the data center administrator150, but of course their access may also be limited to a subset of the VDCs in the data center network100.

FIG. 2is a flowchart of an example network management method200for implementing network virtualization based on MQC.At210, the network management server110receives a command originating from a tenant130of a VDC (e.g. VDC1) in the data center network100. The command is associated with network resource processing based on MQC.At220, based on a network resource configuration140for the VDC of the tenant130, the network management server110processes the command on the network virtualization layer114such that only processing associated with the VDC of the tenant130is performed. As such, the network virtualization layer114of the network management server110therefore facilitates segregation between VDCs in the data center network100.

In one example implementation300inFIG. 3, blocks210and220inFIG. 2may be performed by the first management module112and second management module114respectively.At310(related to210), the network management server110receives the command originating from a tenant of a VDC via the first management module112(see block312). The first management module112then sends the received command to the second management module114for processing (see block314).At320(related to220), the network management server110receives the command via the second management module114(see block322), which functions as a network virtualization layer. Based on a network resource configuration140for the VDC, the second management module114processes the received command such that only processing associated with the VDC of the tenant is performed (see block324). Any result of the processing is then sent by the second management module114to the tenant via the first management module112.

Processing the received command according to blocks220and320may further include identifying the VDC of the tenant130from which the received command originates. The VDC may be identified based on the network resource configuration for the VDC, which stores a corresponding relationship between a VDC and information identifying the VDC. The VDC may be identified using any layer 2, layer 3 and layer 4 information discussed above. For example, the network resource configuration140for a VDC may store a corresponding relationship between a source IP address and the VDC. This allows identification of the VDC from a received command based on its source IP address. Once the VDC is identified, the network management server110may modify the command based on the identified VDC and/or network resource configuration140for the VDC such that only processing associated with the VDC is performed.

The received command controls network resource processing of the VDC of the tenant130based on MQC. The network management server110in turn controls network devices120in the network100through a MQC mechanism. The command may be associated with any suitable network resource processing of the VDC. For example, the command may be a network resource querying command (seeFIG. 4), network resource allocation command (seeFIG. 5), etc.

Network Resource Querying

FIG. 4illustrates an example where the received command is associated with network device querying.At410, a network resource configuration140for each VDC is stored, e.g. by the network management server110. The network resource configuration140for a VDC may include information that allows differentiation of VDCs based on flows. For example, parameters relating to physical network resources (e.g. network devices and interfaces etc.) and/or logical network resources (e.g. source IP address network segment (SRC), VLAN, bandwidth, etc.) may be used.In the example inFIG. 4, the network resource configuration140for VDC1 includes source IP address, VLAN information, device information and a maximum bandwidth:

Network Resource Allocation Command

Another example is shown inFIG. 5, which illustrates the case where the received command is associated with network resource allocation. In the following example, the network resource to be allocated includes bandwidth but it will be appreciated that any other type of network resource may be allocated in a similar manner.At510, a network resource configuration140for each VDC is stored, e.g. by the network management server110. For example, similar to410inFIG. 4, the network resource configuration140for VDC1 may include the following:

From the examples inFIG. 4andFIG. 5, it can be seen that a command received from a tenant of a particular VDC (e.g. VDC1) is processed according to a principle that a tenant within a VDC can only process network resources within its VDC.

To ensure safe transmission of data messages within a particular VDC, different VDCs are isolated from each other. In one example, network devices120of each VDC may be configured with an MQC command that only traffic within each VDC is allowed. Other traffic is discarded by default (except for management or control traffic). Taking VDC1 as an example, the following commands may be configured on the network devices120in VDC1:Class (VDC1 filter to VDC1 filter)→permitClass default→deny

In addition, in one example, if the command would affect segregation among VDCs, the command will not be processed, i.e. the command will be filtered by the second management module114and a failed result will be returned to the tenant130who sends the command via the first management module112. For example, the following command is for modifying the configuration of VDC1 into the configuration of VDC2 to allow mutual communication between them. Since the command affects the isolation or segregation between VDC1 and VDC2, the command will be filtered and a failed result is returned.Set VDC1 to VDC 2→permit.

Example Network Devices600/700

The above examples can be implemented by hardware, software or firmware or a combination thereof. Referring toFIG. 6, an example network device600capable of acting as a network management server110for implementing network virtualization based on MQC.

The example network device600includes a processor610, a memory620and a network interface device640that communicate with each other via bus630. The processor610is to perform processes described herein with reference toFIG. 1toFIG. 6. In one example, the processor610is to perform the following:Receive a command originating from a tenant of a virtual data center (VDC) in the data center network, the command being associated with network resource processing based on MQC.Based on a network resource configuration for the VDC, processing the received command on a network virtualization layer of the network management server such that only processing associated with the VDC of the tenant is performed.

The memory620may store any necessary data622for facilitating implementation of network virtualization based on MQC, e.g. network resource configuration140for each VDC. Of course, as previously explained, the network resource configuration140may be stored on a different device.

The memory620may store machine-readable instructions624executable by the processor610to cause the processor610to perform processes described herein with reference toFIG. 1toFIG. 5. In one example, the instructions624(not shown inFIG. 6for simplicity) may include:Receiving instructions to receive a command originating from a tenant of a virtual data center (VDC) in the data center network, the command being associated with network resource processing based on MQC.Processing instructions to, based on a network resource configuration for the VDC, process the received command on a network virtualization layer of the network management server such that only processing associated with the VDC of the tenant is performed.

In another example shown inFIG. 7, an example device700capable of acting as the network management server110may include the following modules (which may be software, hardware or a combination of both):First management module710(see also112inFIG. 1) to receive a command originating from a tenant of a virtual data center (VDC) in the data center network, the command being associated with network resource processing based on MQC. The first management module710is further to send the command to a second management module720.Second management module720(see also114inFIG. 1) to receive the command from the first management module710and based on a network resource configuration for the VDC, process the received command on a network virtualization layer of the network management server such that only processing associated with the VDC of the tenant is performed.

In one implementation, the second management module720may further include an identification unit to identify the VDC from which the received command originates, and a processing unit to process the received command (e.g. after modifying the command based on the identified VDC). The second management module720may further include a recording unit to record network resource already assigned or allocated to a VDC. The example device700may also further include a storage module to store network resource configuration information.

When processing the received command, the processor610(or second management module720) may be further to identify the VDC of the tenant from which the command originates; and modify the received command based on the identified VDC and/or the network resource configuration for the VDC.

In the case where the received command is a network resource querying command, the processor610(or second management module720) may be further to query, from the network resource configuration for the VDC, a network resource within the identified VDC; and return a query result to the tenant from which the received command originates.

In the case where the received command is a network resource allocation command, the processor610(or second management module720) may be further to allocate a network resource to the identified VDC according to the received command; and return a resource allocation result to the tenant from which the received command originates.

The received command may be associated with allocation of a network resource that comprises bandwidth. In this case, when processing the received command, the processor610(or second management module720) may be further to determine the amount of network resource already allocated to the identified VDC based on a recorded allocation of network resource to the identified VDC. Based on the amount of network resource already allocated to the identified VDC, the processor610(or second management module720) may be further to determine whether allocation of the network resource to the identified VDC would exceed a predetermined maximum amount in the network resource configuration for the VDC. If not exceeded, the network resource is allocated, but otherwise not allocated.

If the received command is a command that affects segregation between the VDC of the tenant and another VDC, the processor610(or second management module720) may be to discard the received command and return a failed result to the tenant from which the received command originates.

The methods, processes and units described herein may be implemented by hardware (including hardware logic circuitry), software or firmware or a combination thereof. The term ‘processor’ is to be interpreted broadly to include a processing unit, ASIC, logic unit, or programmable gate array etc. The processes, methods and functional units may all be performed by the one or more processors610; reference in this disclosure or the claims to a ‘processor’ should thus be interpreted to mean ‘one or more processors’.

Although one network interface device640is shown inFIG. 6, processes performed by the network interface device640may be split among multiple network interface devices (not shown for simplicity). As such, reference in this disclosure to a ‘network interface device’ should be interpreted to mean ‘one or more network interface devices”.

Further, the processes, methods and functional units described in this disclosure may be implemented in the form of a computer software product. The computer software product is stored in a storage medium and comprises a plurality of instructions for making a processor to implement the methods recited in the examples of the present disclosure.

The figures are only illustrations of an example, wherein the units or procedure shown in the figures are not necessarily essential for implementing the present disclosure. Those skilled in the art will understand that the units in the device in the example can be arranged in the device in the examples as described, or can be alternatively located in one or more devices different from that in the examples. The units in the examples described can be combined into one module or further divided into a plurality of sub-units.

Although the flowcharts described show a specific order of execution, the order of execution may differ from that which is depicted. For example, the order of execution of two or more blocks may be changed relative to the order shown. Also, two or more blocks shown in succession may be executed concurrently or with partial concurrence. All such variations are within the scope of the present disclosure.