WO2003090108A1 - A network system having a virtual-service-module - Google Patents

A network system having a virtual-service-module Download PDF

Info

Publication number
WO2003090108A1
WO2003090108A1 PCT/US2003/008272 US0308272W WO03090108A1 WO 2003090108 A1 WO2003090108 A1 WO 2003090108A1 US 0308272 W US0308272 W US 0308272W WO 03090108 A1 WO03090108 A1 WO 03090108A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
virtual
service
service module
module
Prior art date
Application number
PCT/US2003/008272
Other languages
French (fr)
Inventor
David Gary Roberts
Sanjay Dhawah
Mahesh Kumar
Glen William Gibson
Bala Sankaranarayanan
Sam Rajarathinam
Original Assignee
Inkra Networks, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inkra Networks, Inc. filed Critical Inkra Networks, Inc.
Priority to EP03746923A priority Critical patent/EP1499991A4/en
Priority to JP2003586783A priority patent/JP2005523621A/en
Priority to AU2003225847A priority patent/AU2003225847A1/en
Priority to CA002483209A priority patent/CA2483209A1/en
Publication of WO2003090108A1 publication Critical patent/WO2003090108A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • H04L41/122Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

  • This invention generally relates to a network system. More particularly an aspect of this invention relates to a network system employing one or more Nirtual-Service-Modules.
  • a typical standard networking system implemented single-function, fixed functionality.
  • the first generation of virtualized systems offers per-customer functionality, but the functionality is still fixed.
  • Customers may judge service providers based on service availability. Customers may perceive any downtime as a problem with the service provider and may consider switching providers. Service providers want to add service products to their offerings to generate moire revenue and increase margins with higher- value offerings. Some of today's systems require downtime associated with upgrades. This is the case because their systems package all functionality into a single runtime image. It is simpler to design and test a system when all functionality is packaged and released in a single unit. In some cases, the service provider has to minimize downtime by building a redundant topology and taking down one system while the backup system handles service.
  • typical networking systems may offer fixed functionality that is composed in a fixed manner. For instance, processing is usually data link layer L2 followed by network layer L3, or secure socket layer (SSL) acceleration followed by load balancing.
  • processing is usually data link layer L2 followed by network layer L3, or secure socket layer (SSL) acceleration followed by load balancing.
  • SSL secure socket layer
  • networking systems implement fixed functionality with a monolithic version of software.
  • a method, apparatus, and system in which a network system includes a virtual graph composed of a plurality individual networks.
  • a first individual network is associated with a first user.
  • the first individual network includes a plurality of service modules modeled to be representing a first set of network elements.
  • the second individual network is associated with a second user.
  • the second individual network includes a plurality of service modules modeled to be representing a second set of network elements.
  • the second set of network element differs in the type of network elements included in the second individual network and the topological order of the network elements in the second individual network than the first set of network elements.
  • Figure 1 illustrates an embodiment of a network system that includes multiple individual networks to serve the unique network requirements of multiple users.
  • Figure 2 illustrates an embodiment of an architecture of a Virtual-Service-Module modeled to represent a network element that performs one or more functions to process a packet in a network system.
  • Figure 3 illustrates an embodiment of a Virtual-Service-Module container architecture and the Virtual-Service-Module mapping to the physical layer.
  • Figure 4 illustrates an embodiment of an individual network having a topology composed of virtual network elements and physical network elements.
  • Figure 5 A shows an exemplary block diagram illustrating an upgrade of a Virtual- Service-Module according to an embodiment of the invention.
  • Figure 5B shows a flowchart illustrating an exemplary method of upgrading a Virtual- Service-Module according to an embodiment of the invention.
  • Figure 6A shows an exemplary block diagram illustrating changes of a topology of a virtual network system according to an embodiment of the invention.
  • Figure 6B shows a flowchart illustrating an exemplary method of changing a topology according to an embodiment of the invention.
  • Figure 7A shows an exemplary block diagram illustrating changes of a topology of a virtual network system according to an embodiment of the invention.
  • Figure 7B shows a flowchart illustrating an exemplary method of changing a topology according to an embodiment of the invention.
  • a network system includes a virtual graph composed of a plurality individual networks.
  • a first individual network is associated with a first user.
  • the first individual network includes a plurality of service modules modeled to be representing a first set of network elements.
  • the second individual network is associated with a second user.
  • the second individual network includes a plurality of service modules modeled to be representing a second set of network elements.
  • the second set of network element differs in the type of network elements included in the second individual network and the topological order of the network elements in the second individual network than the first set of network elements.
  • Figure 1 illustrates an embodiment of a network system that includes multiple individual networks composed of one or more Virtual-Service-Modules in order to serve the unique network requirements of multiple users.
  • the multiple individual networks 102, 104, 106 compile into the virtual graph l ⁇ o and resources are managed for each individual network in the system according to the user assignment.
  • the network system 100 consists of a first port 110 to the outside world, such as the Internet, a first individual network 102 that includes a first virtual rack 119 housing customer A's network elements, a second individual network 104 that includes a second virtual rack 120 housing customer B's network elements, a third individual network 106 that includes a third virtual rack 121 housing customer C's network elements, a virtual address space assigned to a system management virtual rack 112 housing a management module 114 of the network system, and multiple input output ports 116 connecting the virtual graph 108 to each customer's network 118.
  • virtual graph houses the topologies of all the individual networks 102, 104, 106 but keeps each individual network logically and physically distinct from each other.
  • the virtual graph 100 assigns a separate virtual address space to each individual network 102, 104, 106 within a global domain housing all of the virtual address space.
  • a virtual rack 119-121 is assigned to each user.
  • the virtual rack 119- 121 consists of a virtual address space and hardware resources, such as processing power, bandwidth, and memory, dedicated to that virtual address space.
  • the unique address space and dedicated hardware resources of the virtual rack 119-121 makes each individual network 102, 104, 106 logically and physically distinct from another individual network 102,104,106.
  • a virtual rack 119-121 is a logical receptacle for multiple network-resident application services, such as Virtual-Service-Modules, and is analogous to a physical rack of network appliances.
  • the virtual network topology models the packet-processing functionality in the system as an abstract virtual graph 108 of connected Virtual-Service-Module (VSM) 122-150 nodes.
  • VSM Virtual-Service-Module
  • Each Virtual-Service-Module 122-150 in the system is modeled roughly along the lines of individual network elements in the real world.
  • a Virtual-Service-Module 122-150 may implement functionality approximately that of a standalone IP router, Ethernet switch, a virtual private network, filter/firewall, load balancer, bridge, network address translator, etc.
  • These Virtual-Service-Module 122-150 nodes are then composed in the virtual graph 108 similar to the way they would be in the real world.
  • composition and topology of the Virtual-Service-Modules 122-150 modeled to represent network elements may be arbitrarily assembled based upon a particular customer's desires.
  • customer B's network 104 is composed of different network elements than included in the customer C's network 106.
  • Physical ports 110, 116 on a network switch are attached to the virtual graph 108 at various points and allow the internal virtual system to be coupled to components external to the virtual graph 108.
  • the virtual graph 108 may grow to be very large and come to replace most or all of a typical network data center.
  • the size of the virtual graph 108 may be limited by memory capacity and processing power of the one or more host machines.
  • the virtual graph 108 is hosted on a single computing machine.
  • each Virtual-Service-Module 122-150 models a network element having one or more functions.
  • each Virtual-Service-Module 122-150 modeled to represent a network element provides a discrete service.
  • Each Virtual-Service-Module 122-150 may be composed into the arbitrary topology where packet processing is governed by the configured virtual graph 108 of network services.
  • the support framework software walks the virtual graph of Virtual-Service-Modules in an individual network topology, such as firewall Virtual-Service-Module 132, load balancing Virtual-Service-Module 134, and router Virtual- Service-Module 136, to create a sequential node list for that related packet flow.
  • different individual networksl02, 104, 106 have reserved resources and the exhaustion of resources for one customer does not affect the service levels seen by a second customer.
  • the physical layer performs resource management at the hardware level to ensure that each individual network 102, 104, 106 receives a guaranteed range of the processing and memory resources available in the system and that each individual network 102, 104, 106 cannot interfere with one another.
  • the unique address space and dedicated physical resources assigned to the virtual rack forms a boundary around the Virtual-Service-Modules 122-150 in each individual network 102, 104, 106.
  • the physical layer employs HardWall technology created by Inkra Networks, Inc. located in Fremont, California to manage consumption of system resources and to ensure that a disruptive event occurring in one virtual rack does not affect other virtual racks in the same system.
  • each individual network 102, 104, 106 has processing and memory resources dedicated to that service topology and exhaustion of these dedicated resources for the first individual network is independent from service levels provided to a second individual network.
  • Figure 1 shows three separate virtual racks 119-121, each populated with a number of Virtual-Service-Modules 122-150.
  • the physical layer contains resource management circuit, such as a virtual rack processor employing a token bucket algorithm, to ensure that resources intensive actions, such as a Denial of Service attack, launched against virtual rack A 119 does not cause any decrease in performance in virtual rack B 120 beyond guaranteed levels.
  • Virtual rack A 119 can consume only its specified share of resources; past that, the resource management circuit limits any further consumption to ensure that virtual rack B 120 continues to operate normally.
  • the resource management circuit performs resource management for the entire group of Virtual-Service-Modules within the virtual rack boundaries. This methodology reduces configuration complexity dramatically, because the user is not forced to manually configure resource parameters for each individual Virtual-Service-Module.
  • a user may specify or configure the virtual rack 119-121 through a user interface of the management virtual rack 112.
  • the Virtual-Service-Modules 122-150 in each individual network 102, 104, 106 may be arranged in an arbitrary sequential order.
  • a Virtual-Service-Module modeled to represent a firewall 132 may be placed before or after a Virtual-Service-Module modeled to represent a load balancer 134.
  • customer A's individual network 102 may be composed of different network elements, such as a secure sockets layer 126, a network address translator 128, and a bridge 130, than included in the topology of customer B's individual network 104.
  • each customer in the virtual graph 108 may tailor the arrangement and functionality of the Virtual- Service-Modules in the individual network topology 102, 104, 106 associated with that customer to the unique requirements needed by that customer. Further, a customer/user can manage a virtual rack 119-121 populated with one or more Virtual-Service-Module instances 122-150 as a single unit within the network system 100.
  • FIG. 2 illustrates an embodiment of an architecture of a Virtual-Service-Module modeled to represent a network element that performs one or more functions to process a packet in a network system.
  • the architecture of an instance of a Virtual-Service-Module 200 may be composed of multiple cooperating parts. In this way, a Virtual-Service-Module 200 is actually a high-level abstraction composed of multiple sub-parts.
  • the sub-components include a Management component 201, a Flow setup component 202, and a Packet-processing component 203.
  • Each Virtual-Service-Module instance 200 also may have ports that describe its relation to other components and have interfaces to communicate with components external to the virtual network system. The ports are used by both the management component 201 and the flow setup component 202.
  • the management component 201 directs interfacing with the various management interfaces common to the components internal to the virtual system.
  • the management component 201 also maintains any global information required.
  • the management component 201 gathers information by communicating with external entities such as routers and authentication authorities.
  • the management component 201 may dynamically configure the virtual service module 200.
  • the flow setup component 202 performs initial packet-processing, determining the packet path through the virtual network graph, and building an action list for the flow.
  • Flow may be a particular stream of related packets.
  • the packet-processing component 203 is an abstract piece of the Virtual-Service- Module 200.
  • the packet-processing component 203 may contain an action list of standard processing primitive instructions programmed into a hardware accelerator application specific integrated circuit.
  • a Virtual-Service-Module that requires packet processing beyond what the standard primitive instructions in the packet-processing component 203 can accomplish would continue to process the packets in the flow set-up processing component 202.
  • a Virtual-Service- Module that starts each related packet flow as this type of extended flow setup can bind an action list at any time, but in some cases the Virtual-Service-Module processes the entire related packet flow without ever switching to hardware assist.
  • each Virtual-Service-Module 200 is a self-contained module of data and its associated processing software that has an archive file containing both executable code as well as metadata that integrates the service module with the network system.
  • the executable code includes instructions to install and remove that instance of the Virtual-Service- Module 200. Further, the executable code includes instructions to configure that instance of the Virtual-Service-Module 200 with configuration information.
  • each Virtual-Service- Module 200 may contain data and its associated processing software to model a discrete network element such as a firewall, a filter, a load balancer, a router, etc.
  • a Virtual-Service-Module 200 belongs to an object class in which one or more instances of each Virtual-Service-Module 200 may exist.
  • Objects may be independent program modules written in object-oriented programming languages. Objects are software components structured to plug into and work with each other at runtime without any prior linking or precompilation as a group.
  • One or more instances of particular type of Virtual- Service-Module 200 may be created.
  • each VSM component may be contained in a single container application, just as long as the service module is modeled to represent a network element.
  • the class of Virtual-Service-Modules modeled to represent firewalls 132, 138 may have multiple instances of that Virtual-Service-Module plugged into multiple customers' virtual racks 120, 121 throughout the virtual graph 108.
  • the classes of Virtual-Service-Modules modeled to represent network elements are created in hierarchies, and inheritance allows the knowledge in one class in a layer higher in the hierarchy to be passed down to another class lower in the hierarchy, such as an instance of a VSM firewall.
  • Virtual-Service-Modules 200 may be packaged in separate binary images. The image contains an archive file of both executable code as well as metadata that integrates the Virtual-Service-Module 200 with the system.
  • the meta data includes information that describes the various configuration parameters supported by the Virtual-Service-Module, versioning information, resources required, dependency information, and any specific commands required to configure the module through the command-line interface (CLI).
  • CLI command-line interface
  • the network system can easily integrate the Virtual-Service- Module 200 without the user known what functionality is "built-in" to the base system and what has been added later.
  • extendable markup language XML may be used to format the meta data.
  • an action list may be a list of processing primitive instructions that a Virtual-Service-Module wants applied to each packet in a given related packet flow.
  • Processing primitive instructions may be a single, primitive instruction packet transformation operation. For example, decrementing the IP TTL field or recomputing the IP checksum field are each processing primitive instructions.
  • a combined action list is the concatenation of each Virtual-Service-Module 's action list for all the nodes in a given sequential node list.
  • a common action list is a global action list applied to all arriving packets.
  • An optimized action list is the combined action list after it has been optimized.
  • a Virtual-Service-Module 200 may have three types of addressing perspectives.
  • the most familiar addressing perspective is the router-like Virtual-Service-Module 124, 136 that performs "normal" routing functions.
  • the other two Virtual-Service-Module addressing perspectives can be restricted to two ports, which means that no routing decisions will be required.
  • These two addressing perspectives are the addressable bump and the anonymous bump that make forwarding decisions.
  • the firewall Virtual-Service-Module 132, 138 can be an anonymous bump that decides which packets to drop, but once a decision to forward the packet has been made, there is no choice as to which port the packet should be sent.
  • An addressable bump may be, for example, a Virtual Private Network.
  • Figure 3 illustrates an embodiment of a Virtual-Service-Module container architecture and the Virtual-Service-Module mapping to the physical layer.
  • the container program consists of two or more sub-programs. Each sub-program is programmed for a specific function such as a management container 302, a flow setup container 304, and a packet- processing container 306.
  • the container architecture may use the three different types of containers 302, 304, 306 to manage the three individual components of a Virtual-Service- Module, the management component 308, a flow setup component 310, and a packet-processing component 312.
  • the management container 302, the flow setup container 304, and the packet-processing container 306 may be included as portions of the operating system software.
  • the management component 308 may embed in the management container 302.
  • the flow setup component 310 may embed in the flow setup container 304.
  • the packet- processing component 312 may embed in the packet processing container 306.
  • the management container 308 provides various common management interfaces such as SNMP, web, and CLI, and allows the Virtual-Service-Module to interact with that functionality.
  • the flow setup container 304 wraps the Virtual-Service-Module flow setup component 310 and provides for the dispatching of new related packet flows to flow setup components.
  • the flow setup container 304 provides the creation and optimization of action lists.
  • the packet-processing container 306 manages the optimized combined processing list transferred from the flow setup module 310 on a per-flow basis.
  • a Virtual-Service-Module such as Virtual-Service-Module 322, may interact with another Virtual-Service-Module though the container program.
  • no Virtual- Service-Module contains a direct object reference to another Virtual-Service-Module. This makes it much easier to alter the virtual network graph and upgrade Virtual-Service-Modules without having to worry about other Virtual-Service-Modules holding stale object references. Therefore, Virtual-Service-Modules can operate in total isolation without having to worry about what other Virtual-Service-Modules may exist in the chain and the various lifecycle changes those other Virtual-Service-Modules may be going through.
  • the management container 302, flow setup container 304, and packet-processing container 306 implement various portions of a Virtual-Service-Module's Application Program Interface.
  • the management container 302 provides API functions to install and remove a Virtual-Service-Module, to configure a Virtual-Service-Module with both box- wide and content-provider-specific configuration information, and to manage a Virtual-Service- Module.
  • the flow setup container 304 provides API functions to dispatch new related packet flows, build and manage the creation of optimized processing lists, and the packet flow transfers to the packet-processing module, manipulate packet contents, and manipulate related packet flow state.
  • the packet-processing container 306 performs packet processing on the fast path and resides in the packet-processing physical implementation.
  • the packet-processing container provides some of the services of the flow setup container, but eliminates most of the functions that deal with high-level issues such as Virtual-Service-Module configuration and lifecycle management.
  • the packet-processing container 306 provides functions to manipulate packet contents, manipulate related packet flow state, and inform the flow setup container of flow termination, which is then passed on to the appropriate Virtual-Service-Module flow setup component 310.
  • the management component 308, flow setup component 310, and packet-processing component 312 of the Virtual-Service-Module 322 may be embedded or linked into the container program.
  • These components of the VSM 308, 310, 312 can be linked instead of embedded, in which case the container application does not physically hold the component of the VSM, but provides a pointer to it. If a change is made to a linked component of the VSM, all the documents that contain the same link are automatically updated the next time you open them. If these components 308, 310, 312 are embedded, then the container that contains a copy of that component. Changes made to that component of the VSM affect only the container program that contains that instance of the component.
  • VSM Voice over IP
  • the container program may provide common functions such as security and transaction support and delivers a consistent interface to the applications regardless of the type of server. The ultimate goal of objects is that it should not matter which source language they were programmed in or which computer on the network they are running in.
  • Virtual- Service-Modules interoperate through the messages passed between the container program. [0042] Each of the Virtual-Service-Module components 308, 310, 312 may be mapped to a different physical circuit board 314, 316, 318.
  • the physical layer of the virtual network system may have several types of circuit modules such as a Management module 314, a service processing module that includes a Flow processing module 316 as well as a packet processing module 318, and an I/O module.
  • the management module 314 includes the switch fabric hardware.
  • the switch fabric hardware consists of a data-passing board in the chassis.
  • Each flow set up module 316 (FPM) may contain one or more flow processing engines.
  • Each flow processing engine may include a General Purpose Processor and an application specific integrated circuit to process packeted information such as a packet-processing hardware accelerator.
  • Each packet processing module 318 may contain one or more flow processing engines.
  • Each flow processing engine is an addressable end point on the data passing hardware connecting board in the chassis.
  • the input-output (I/O) module supports one or more external I/O ports via one or more VO engines.
  • the management component 308 of the Virtual-Service-Module can map to and run on the management module 314.
  • the flow setup component 310 maps to and runs on a General- Purpose-Processor on one of the Flow-Processing-Engines. Packet processing may handled in the packet-processing hardware accelerator, with special cases handled via exceptions passed to the General-Purpose-Processor.
  • FIG. 4 illustrates an embodiment of an individual network having a topology composed of virtual network elements and physical network elements.
  • the first individual network 402 includes a virtual rack 419 housing customer A's virtual network elements.
  • the virtual rack 419 couples via a port 416 to the customer A's network 418.
  • the virtual rack 419 couples via a second port 425 to a physical network element, such as a firewall 452.
  • An SSL Virtual-Service-Module 426 of the individual network associated with customer A 402 receives packets from the system router Virtual-Service-Module 424.
  • the SSL Virtual-Service-Module 426 forwards the packets to the physical firewall 452 via the second port 425.
  • the physical firewall 452 forwards the packets via the second port 425 to a NAT Virtual-Service-Module 428.
  • the NAT Virtual-Service-Module 428 routes the packets to the bridge Virtual-Service-Module 430.
  • the packets exit the topology of the individual network associated with customer A 402 to the customer's network 418 via multiple ports 416.
  • the physical layer contains one or more virtual rack processors.
  • Each virtual rack processor manages the flow of data through the physical layer, allocates resources for each virtual rack 419, and performs high-speed packet processing to implement a particular service. Because the virtual rack 419 uses hardware-based resource management, the virtual rack 419 is more efficient, accurate, and secure than software-based schemes.
  • the virtual rack processor subsystem's activities can be divided into three main categories, Queuing and high-speed processing, Managing general processing resources, and Dealing with the integrity and security of the virtual rack.
  • each virtual rack processor assigns multiple queues to each virtual rack 419 in the system.
  • the virtual rack processor services these queues using a token bucket algorithm that ensures that each virtual rack receives its share of the VRP processing resources.
  • the virtual rack processor manages the virtual rack queues in a very large memory area with large buffering capability. By allocating multiple queues per virtual rack, the virtual rack processor ensures that no one virtual rack 419 is able to consume all the available buffer memory at the expense of a second virtual rack 420.
  • the token bucket logic assures that every virtual rack has fair access to the virtual rack processor processing unit.
  • the virtual rack processor decides that a particular packet requires extensive high level processing, it forwards the packet to the general processing block for further attention and moves on to processing the next packet in its queues.
  • the virtual rack processor implements a second set of queuing logic. As with the first set of queues, each virtual rack 419-421 in the system is assigned queues in the second set.
  • the virtual rack processor manages this second set of queues and forwards packets to the general processing block as required. This keeps the general processing block fed, and delivers the highest possible throughput.
  • the virtual rack processor subsystem schedules the next packet for the general processing block to ensure that processing resources are distributed according to physical layer resource allocations.
  • the virtual rack processor subsystem allocates a memory area for each virtual rack 419-421 in the system.
  • the memory area stores packets and service state information associated with the particular virtual rack, such as virtual rack A 419.
  • the system monitors each area closely for resource consumption. If a particular virtual rack, such as virtual rack A 419, encroaches on a physical layer memory allocation limit, it is not allowed to expand further at the expense of other virtual racks. This behavior ensures that no one virtual rack 419-421 can monopolize memory resources at the expense of the others.
  • the physical layer uses a hardware memory management unit (MMU) to create a protection domain for each virtual rack 419-421.
  • MMU hardware memory management unit
  • the protection domain isolates the impact to the particular virtual rack 419-421 where the service is located.
  • the protection domain associated with the virtual rack 419-421 is flushed, and the virtual rack 419-421 is automatically restarted. In this way, the system contains service faults to the virtual rack 419-421 where they originate, preventing them from propagating to other virtual racks 419-421 or affecting their processing.
  • the processing block When working on a packet, the processing block first enters the protection domain associated with the virtual rack 419-421 to which the packet belongs.
  • the processing block can only access memory associated with the virtual rack 419-421, assuring the security of the system. Any attempt to access memory resources outside the protection domain is treated as a service crash — in which case the protection domain is flushed and the virtual rack 419-421 is restarted.
  • each Virtual-Service-Module 424, 426, 428, 430 may be dynamically loaded or unloaded through a user interface of the management virtual rack 412. Multiple instances of the Virtual-Service-Modules may be loaded simultaneously, such as router Virtual- Service-Modules 424 and 436. Further, multiple instances of Virtual-Service-Modules may contain different versions. For example, router Virtual-Service-Module 424 may have different version than the router Virtual-Service-Module 436. Each Virtual-Service-Module can be changed or upgraded individually without disrupting other services of the other Virtual-Service- Modules.
  • FIG. 5 A shows an exemplary block diagram illustrating an upgrade of a Virtual- Service-Module according to an embodiment of the invention.
  • an initial configuration 501 of a topology processes a data flow through router Virtual-Service-Module 504, a firewall Virtual-Service-Module 505, a secure socket layer (SSL) Virtual-Service-Module version 1506, and a load balancer Virtual-Service-Module 507.
  • SSL secure socket layer
  • FIG. 5A shows an exemplary block diagram illustrating an upgrade of a Virtual- Service-Module according to an embodiment of the invention.
  • an initial configuration 501 of a topology processes a data flow through router Virtual-Service-Module 504, a firewall Virtual-Service-Module 505, a secure socket layer (SSL) Virtual-Service-Module version 1506, and a load balancer Virtual-Service-Module 507.
  • SSL Virtual-Service-Module version II 508 is launched.
  • the system connect the SSL Virtual-Service-Module 508 to the firewall Virtual-Service-Module 505 through the edge 509 and to the load balancer Virtual-Service-Module 507 through the edge 510.
  • the SSL Virtual-Service-Module version II 508 and the SSL Virtual-Service-Module version 1506 are running in parallel, as shown in configuration 502.
  • the system then directs any new flow data to the newly executed SSL Virtual- Service-Module version II 508.
  • the SSL Virtual-Service-Module 508 processes the new data flow and transmit the data to the load balancer Virtual-Service-Module 507 thereafter.
  • the system continue direct the existing data flow to the SSL Virtual-Service-Module version 1506.
  • This parallel processing continues until certain conditions are satisfied.
  • the condition may be a pre-specified amount data of existing flow waiting for processing.
  • the condition may be a pre-specified period of time. Anytime before this condition is reached, the upgrade can be aborted instantaneously through the user interface of the management virtual rack.
  • the system directs all of the traffics to the new SSL Virtual-Service-Module 508. Once the SSL Virtual-Service-Module 508 stabilizes, the system disconnects the edges 511 and 512 between the SSL Virtual-Service-Module 506 and the firewall Virtual-Service-Module 505 and load balancer Virtual-Service-Module 507 respectively. Thereafter, the SSL Virtual-Service-Module 506 is terminated and removed from the graph, as shown in configuration 503. As a result, SSL Virtual-Service-Module service has been upgraded dynamically and the services being provided originally by SSL Virtual-Service-Module 506 is not disrupted.
  • the system directs all the new flow data to the old SSL Virtual-Service-Module version 1506.
  • the system disconnects the edges 509 and 510. This takes the virtual rack to its original state before the upgrade was started. All the flows that started going through the SSL Virtual-Service-Module 508 are terminated by the system. The old flows that were going through the SSL Virtual-Service-Module version 1506 will continue to go through without any change.
  • Figure 5B shows a flowchart illustrating an exemplary method of upgrading a Virtual- Service-Module according to an embodiment of the invention.
  • the method illustrates processing a request for changing a first node having a first service connecting with a second node and a third node in a network environment.
  • the method includes dynamically launching a second service at the first node, connecting the second service with the second and the third nodes, directing requests for service to the second service, and terminating the first service.
  • the method further includes determining whether the requests for service come from a new session of data, transmitting the requests for service to the second service if the requests for service come from a new session of data, and transmitting the requests for service to the first service if the requests for service come from an existing session of data.
  • the system dynamically launches a new service (e.g., an instance of a Virtual-Service-Module with upgraded version), while the existing service (e.g., the existing Virtual-Service-Module needed to be upgraded) still processing the data flow from a first node to a second node.
  • the system connects the new Virtual-Service-Module to the first and second nodes.
  • the system then directs the new flow of data to the new Virtual-Service-Module, while directing the existing flow of data to the existing Virtual-Service-Module for processing.
  • the new and existing flows of data are processed in parallel by the new and existing Virtual-Service- Modules respectively.
  • the system checks whether a pre-specified condition has been satisfied.
  • the condition may be an amount of existing flow of data remains to be processed. In an alternative embodiment, the condition may be a period of time remained. Other conditions may be utilized. The parallel processes continue until the condition is satisfied.
  • the system directs all data flows to the new Virtual-Service-Module and terminates the existing Virtual-Service-Module at block 556.
  • a new instance of the service module having different functionality than the existing instance of the service module may load during program execution, specifically, long after the initial start-up phase.
  • FIG. 557 shows an exemplary block diagram illustrating changes of a topology of a virtual network system according to an embodiment of the invention.
  • an initial configuration 601 of a topology processes a data flow through router VSM 604, a firewall VSM 605, a secure socket layer (SSL) VSM 606, and a load balancer VSM 607.
  • a change request e.g., adding a VPN VSM to the graph
  • SSL secure socket layer
  • a change request e.g., adding a VPN VSM to the graph
  • an instance of VPN VSM 608 is launched.
  • the system connect the VPN VSM 608 to the firewall VSM 605 through the edge 609 and to the load balancer VSM 607 through the edge 610.
  • the VPN VSM 608 and the edge 611 connecting VSM 606 and VSM 605 are running in parallel, as shown in configuration 602.
  • the system then directs any new flow data to the newly executed VPN VSM 608.
  • the VPN VSM 608 processes the new data flow and transmits the data to the SSL VSM 606 thereafter.
  • the system continues direct the existing data flow to the SSL VSM 606 through the edge 611. This parallel processing continues until certain conditions are satisfied.
  • the condition may be a pre-specified amount data of existing flow waiting processing.
  • the condition may be a pre-specified period of time.
  • the change of the topology can be aborted anytime before the conditions to commit are satisfied. If the conditions are not met first, the configuration looks like 603. If the change is aborted before the conditions are met, it is reverted back to the original configuration 601.
  • the system directs all of the traffic to the new VPN VSM 608. Once system clears all old related packets of flow from the VPN VSM 608, the system disconnects the edges 611 between the SSL VSM 606 and the firewall VSM 605. As a result, VPN VSM service has been added to the graph dynamically and the services being provided originally by the edge 611 is not disrupted.
  • the system directs all of the new flow data to SSL Virtual- Service-Module 606 through the edge 611.
  • the system continues to direct the existing data flow to the SSL VSM 606 through the edge 611.
  • the system disconnects the edges 609 and 610, and the VPN Virtual-Service-Module 608. Thus restoring the original topology.
  • Figure 6B shows a flowchart illustrating an exemplary method of changing a topology according to an embodiment of the invention.
  • the method illustrates processing a request for changing a topology having a direct connection between a first node and a second node in a network environment.
  • the method includes dynamically launching a new service, the service intended to be added between the first and second nodes, connecting the new service with the first and the second nodes, directing requests for service to the new service from the first node and thereafter transmit the requests to the second node, and terminating the direct connection between the first and second node.
  • the method further includes determining whether the requests for service come from a new session of data, transmitting the requests for service to the new service if the requests for service come from a new session of data, and transmitting the requests for service to the direct connection between the first and second nodes if the requests for service come from an existing session of data.
  • the system dynamically launches a new service, the new service is intended to be added between a first node and a second node, the first and the second nodes are connected directly to each other through an edge.
  • the system connects the new service to the first and the second nodes.
  • the system then directs the new data flow to the new service from the first node, the new service processes new data flow and transmits the data to the second node.
  • FIG. 7A shows an exemplary block diagram illustrating changes of a topology of a virtual network system according to an embodiment of the invention.
  • an initial configuration 701 of a topology processes a data flow through router VSM 704, a firewall VSM 705, a VPN VSM 706, and a load balancer VSM 707.
  • an edge 708 is created to connect the firewall VSM 705 and the load balancer VSM 707.
  • the system instructs the firewall VSM 705 to transmit any new data flow to the load balancer VSM 707 directly through the edge 708, while the existing data flow is transmitted by the firewall VSM 705 to the load balancer VSM 707 through the VPN VSM 706.
  • the edge 708 and the VPN VSM 706 are running in parallel, as shown in configuration 602. This parallel processing continues until certain conditions are satisfied.
  • the condition may be a pre-specified amount data of existing flow waiting processing. In an alternative embodiment, the condition may be a pre- specified period of time.
  • the system directs all of the traffics from the firewall VSM 705 directly to the load balancer VSM 707 through the edge 708. Once the data processing of the edge 708 stabilizes, the system disconnects the edges 709 and 710 between the VPN VSM 706 and the firewall VSM 705 and the load balancer VSM 707. Thereafter, the VPN VSM 706 is terminated and removed from the graph. As a result, VPN VSM service has been deleted from the graph dynamically and the services being provided originally by the VPN VSM 706 is not disrupted.
  • Figure 7B shows a flowchart illustrating an exemplary method of changing a topology according to an embodiment of the invention.
  • the method illustrates processing a request for changing a topology having a first node, a second node, and a third node, the first node being directly connected to the second node and the second node being directly connected to the third node.
  • the method includes dynamically connecting the first and third nodes, directing requests for service directly from the first node to the second node, and terminating the second node.
  • the method further includes determining whether the requests for service come from a new session of data, transmitting the requests for service directly from the first node to the second node, if the requests for service come from a new session of data, and transmitting the requests for service from the first node to the second node and from second node to the third node, if the requests for service come from an existing session of data.
  • the system dynamically connects a first node and a third node, wherein the first and the third node are connect through a second node in between.
  • the system directs the new data flow to the direct connection between the first and third nodes.
  • the second node is still processing the existing data flow received from the first node and thereafter transmitting the data to the third node. This parallel processing continues until a set of conditions is satisfied at block 753.
  • the system directs all data flows from the first node directly to the third node without going through the second node.
  • the second node is terminated and removed from the graph, since it is no longer needed.
  • the system checks to see if the change is aborted. In block 758, if the change is aborted then the system directs all the new data flow from the first node to the second node. Also, the system terminates any remaining flow going between the first node and third node. In block 759, the system deletes the edge connecting the first node and third node.
  • the software used to facilitate the algorithms can be embodied onto a computer-readable medium.
  • a computer -readable medium includes any mechanism that provides (e.g., stores and/or transmits) information in a form readable by a machine (e.g., a computer).
  • a machine-readable medium includes read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; DVD's, electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, EPROMs, EEPROMs, FLASH, magnetic or optical cards, or any type of media suitable for storing electronic instructions. Slower mediums could be cached to a faster, more practical, medium.

Abstract

A method, apparatus, and system in which a network system includes a virtual graph composed of a plurality individual networks. A first individual network (119) is associated with a first user. The first individual network (119) includes a plurality of service modules (126, 128, 130) modeled to be representing a first set of network elements. The second individual network (120) is associated with a second user. The second individual network (120) includes a plurality of service modules (132, 134,136) modeled to be representing a second set of network elements. The second set of network element differs in the type of network elements included in the second individual network and the topological order of the network elements in the second individual network than the first set of network elements.

Description

A NETWORK SYSTEM HAVING A VIRTUAL-SERNtCE-MODU E
NOTICE OF COPYRIGHT
[001] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the software engines and modules, as they appears in the Patent and Trademark Office Patent file or records, but otherwise reserves all copyright rights whatsoever.
FIELD OF THE INVENTION
[002] This invention generally relates to a network system. More particularly an aspect of this invention relates to a network system employing one or more Nirtual-Service-Modules.
BACKGROUND OF THE INVENTION
[003] A typical standard networking system implemented single-function, fixed functionality. The first generation of virtualized systems offers per-customer functionality, but the functionality is still fixed. These limitations lead to several drawbacks. Customers may judge service providers based on service availability. Customers may perceive any downtime as a problem with the service provider and may consider switching providers. Service providers want to add service products to their offerings to generate moire revenue and increase margins with higher- value offerings. Some of today's systems require downtime associated with upgrades. This is the case because their systems package all functionality into a single runtime image. It is simpler to design and test a system when all functionality is packaged and released in a single unit. In some cases, the service provider has to minimize downtime by building a redundant topology and taking down one system while the backup system handles service. This is non-optimal because it forces the service provider to purchase redundant hardware and design complex configurations. To achieve economies of scale and lower capital expenditures, service providers are installing systems that service multiple customers on a single system. Rather than dedicating hardware to each individual customer, the service provider amortizes that capital expense across many customers, lowering the average cost. These service providers typically schedule downtime with their customers for routine maintenance. This scheduling is more difficult when multiple customers are configured to utilize the same system. [004] In addition, typical networking systems may offer fixed functionality that is composed in a fixed manner. For instance, processing is usually data link layer L2 followed by network layer L3, or secure socket layer (SSL) acceleration followed by load balancing. Typically, networking systems implement fixed functionality with a monolithic version of software. Those systems that offer Virtual loading typically use a simple link-time configuration strategy or simple Virtual loading at start time, but not thereafter. Thus, you may get to choose what functionality you want to run at startup time, but you cannot change it thereafter. Typically, prior systems have had disadvantages such as they require a reboot when they are upgraded. This causes downtime. As a result, some conventional systems lack the ability to configure functionality in an arbitrary manner using an arbitrary topology, to add new functionality to a running system without causing downtime, or to upgrade a portion of functionality to a new revision.
[005] Furthermore, in data centers, from time to time they have to upgrade the software running on a packet processing system or change the network topology or upgrade the hardware. Any upgrade of software or hardware disrupts the service availability. Such upgrades are normally done during the maintenance hours in which the service is not available to the customers. Alternatively, the service network is duplicated so that the service is available on one of networks always. i the first approach, service is disrupted. In the second approach, redundant network must be setup and maintained carefully.
[006] Therefore, a better solution is highly desirable to be able to compose, manage, change, or upgrade a topology of a network system.
SUMMARY OF THE INVENTION
[007] A method, apparatus, and system in which a network system includes a virtual graph composed of a plurality individual networks. A first individual network is associated with a first user. The first individual network includes a plurality of service modules modeled to be representing a first set of network elements. The second individual network is associated with a second user. The second individual network includes a plurality of service modules modeled to be representing a second set of network elements. The second set of network element differs in the type of network elements included in the second individual network and the topological order of the network elements in the second individual network than the first set of network elements. BRIEF DESCRIPTION OF THE DRAWINGS
[008] The drawings refer to the invention in which:
Figure 1 illustrates an embodiment of a network system that includes multiple individual networks to serve the unique network requirements of multiple users.
Figure 2 illustrates an embodiment of an architecture of a Virtual-Service-Module modeled to represent a network element that performs one or more functions to process a packet in a network system.
Figure 3 illustrates an embodiment of a Virtual-Service-Module container architecture and the Virtual-Service-Module mapping to the physical layer.
Figure 4 illustrates an embodiment of an individual network having a topology composed of virtual network elements and physical network elements.
Figure 5 A shows an exemplary block diagram illustrating an upgrade of a Virtual- Service-Module according to an embodiment of the invention.
Figure 5B shows a flowchart illustrating an exemplary method of upgrading a Virtual- Service-Module according to an embodiment of the invention.
Figure 6A shows an exemplary block diagram illustrating changes of a topology of a virtual network system according to an embodiment of the invention.
Figure 6B shows a flowchart illustrating an exemplary method of changing a topology according to an embodiment of the invention.
Figure 7A shows an exemplary block diagram illustrating changes of a topology of a virtual network system according to an embodiment of the invention.
Figure 7B shows a flowchart illustrating an exemplary method of changing a topology according to an embodiment of the invention.
[009] While the invention is subject to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will herein be described in detail. The invention should be understood to not be limited to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.
DETAILED DISCUSSION
[0010] In the following description, numerous specific details are set forth, such as examples of specific data signals, named components, connections, number of networks, etc., in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well known components or methods have not been described in detail but rather in a block diagram in order to avoid unnecessarily obscuring the present invention. Further specific numeric references such as first driver, may be made. However, the specific numeric reference should not be interpreted as a literal sequential order but rather interpreted that the first Virtual-Service-Module is different than a second Virtual-Service-Module. Thus, the specific details set forth are merely exemplary. The specific details may be varied from and still be contemplated to be within the spirit and scope of the present invention. The term packet may be a block of data used for transmission in packet switched systems. The terms frame, packet and datagram are often used synonymously.
[0011] In general, a method, apparatus, and system are described in which a network system includes a virtual graph composed of a plurality individual networks. A first individual network is associated with a first user. The first individual network includes a plurality of service modules modeled to be representing a first set of network elements. The second individual network is associated with a second user. The second individual network includes a plurality of service modules modeled to be representing a second set of network elements. The second set of network element differs in the type of network elements included in the second individual network and the topological order of the network elements in the second individual network than the first set of network elements.
[0012] Figure 1 illustrates an embodiment of a network system that includes multiple individual networks composed of one or more Virtual-Service-Modules in order to serve the unique network requirements of multiple users. The multiple individual networks 102, 104, 106 compile into the virtual graph lόo and resources are managed for each individual network in the system according to the user assignment. The network system 100 consists of a first port 110 to the outside world, such as the Internet, a first individual network 102 that includes a first virtual rack 119 housing customer A's network elements, a second individual network 104 that includes a second virtual rack 120 housing customer B's network elements, a third individual network 106 that includes a third virtual rack 121 housing customer C's network elements, a virtual address space assigned to a system management virtual rack 112 housing a management module 114 of the network system, and multiple input output ports 116 connecting the virtual graph 108 to each customer's network 118. In an embodiment, virtual graph houses the topologies of all the individual networks 102, 104, 106 but keeps each individual network logically and physically distinct from each other.
[0013] In an embodiment, the virtual graph 100 assigns a separate virtual address space to each individual network 102, 104, 106 within a global domain housing all of the virtual address space. In an embodiment, a virtual rack 119-121 is assigned to each user. The virtual rack 119- 121 consists of a virtual address space and hardware resources, such as processing power, bandwidth, and memory, dedicated to that virtual address space. The unique address space and dedicated hardware resources of the virtual rack 119-121 makes each individual network 102, 104, 106 logically and physically distinct from another individual network 102,104,106. In an embodiment, a virtual rack 119-121 is a logical receptacle for multiple network-resident application services, such as Virtual-Service-Modules, and is analogous to a physical rack of network appliances.
[0014] The virtual network topology models the packet-processing functionality in the system as an abstract virtual graph 108 of connected Virtual-Service-Module (VSM) 122-150 nodes. Each Virtual-Service-Module 122-150 in the system is modeled roughly along the lines of individual network elements in the real world. For instance, a Virtual-Service-Module 122-150 may implement functionality approximately that of a standalone IP router, Ethernet switch, a virtual private network, filter/firewall, load balancer, bridge, network address translator, etc. These Virtual-Service-Module 122-150 nodes are then composed in the virtual graph 108 similar to the way they would be in the real world.
[0015] Note, the composition and topology of the Virtual-Service-Modules 122-150 modeled to represent network elements may be arbitrarily assembled based upon a particular customer's desires. For example, customer B's network 104 is composed of different network elements than included in the customer C's network 106. Physical ports 110, 116 on a network switch are attached to the virtual graph 108 at various points and allow the internal virtual system to be coupled to components external to the virtual graph 108.
[0016] The virtual graph 108 may grow to be very large and come to replace most or all of a typical network data center. The size of the virtual graph 108 may be limited by memory capacity and processing power of the one or more host machines. In an embodiment, the virtual graph 108 is hosted on a single computing machine.
[0017] As noted, the network system 100 may have variable functionality representing discrete "services". Each Virtual-Service-Module 122-150 models a network element having one or more functions. In an embodiment, each Virtual-Service-Module 122-150 modeled to represent a network element provides a discrete service.
[0018] Each Virtual-Service-Module 122-150 may be composed into the arbitrary topology where packet processing is governed by the configured virtual graph 108 of network services. As each related packet flow is introduced to the system, the support framework software walks the virtual graph of Virtual-Service-Modules in an individual network topology, such as firewall Virtual-Service-Module 132, load balancing Virtual-Service-Module 134, and router Virtual- Service-Module 136, to create a sequential node list for that related packet flow. [0019] As noted, different individual networksl02, 104, 106 have reserved resources and the exhaustion of resources for one customer does not affect the service levels seen by a second customer. The physical layer performs resource management at the hardware level to ensure that each individual network 102, 104, 106 receives a guaranteed range of the processing and memory resources available in the system and that each individual network 102, 104, 106 cannot interfere with one another. The unique address space and dedicated physical resources assigned to the virtual rack forms a boundary around the Virtual-Service-Modules 122-150 in each individual network 102, 104, 106. In an embodiment, the physical layer employs HardWall technology created by Inkra Networks, Inc. located in Fremont, California to manage consumption of system resources and to ensure that a disruptive event occurring in one virtual rack does not affect other virtual racks in the same system. Thus, each individual network 102, 104, 106 has processing and memory resources dedicated to that service topology and exhaustion of these dedicated resources for the first individual network is independent from service levels provided to a second individual network.
[0020] For example, Figure 1 shows three separate virtual racks 119-121, each populated with a number of Virtual-Service-Modules 122-150. The physical layer contains resource management circuit, such as a virtual rack processor employing a token bucket algorithm, to ensure that resources intensive actions, such as a Denial of Service attack, launched against virtual rack A 119 does not cause any decrease in performance in virtual rack B 120 beyond guaranteed levels. Virtual rack A 119 can consume only its specified share of resources; past that, the resource management circuit limits any further consumption to ensure that virtual rack B 120 continues to operate normally. Because multiple Virtual-Service-Modules 122-150 can be installed into a virtual rack 119-121, the resource management circuit performs resource management for the entire group of Virtual-Service-Modules within the virtual rack boundaries. This methodology reduces configuration complexity dramatically, because the user is not forced to manually configure resource parameters for each individual Virtual-Service-Module. [0021] In one embodiment, a user may specify or configure the virtual rack 119-121 through a user interface of the management virtual rack 112.
[0022] The Virtual-Service-Modules 122-150 in each individual network 102, 104, 106 may be arranged in an arbitrary sequential order. A Virtual-Service-Module modeled to represent a firewall 132 may be placed before or after a Virtual-Service-Module modeled to represent a load balancer 134. Further, customer A's individual network 102 may be composed of different network elements, such as a secure sockets layer 126, a network address translator 128, and a bridge 130, than included in the topology of customer B's individual network 104. Thus, each customer in the virtual graph 108 may tailor the arrangement and functionality of the Virtual- Service-Modules in the individual network topology 102, 104, 106 associated with that customer to the unique requirements needed by that customer. Further, a customer/user can manage a virtual rack 119-121 populated with one or more Virtual-Service-Module instances 122-150 as a single unit within the network system 100.
[0023] Figure 2 illustrates an embodiment of an architecture of a Virtual-Service-Module modeled to represent a network element that performs one or more functions to process a packet in a network system. The architecture of an instance of a Virtual-Service-Module 200 may be composed of multiple cooperating parts. In this way, a Virtual-Service-Module 200 is actually a high-level abstraction composed of multiple sub-parts. The sub-components include a Management component 201, a Flow setup component 202, and a Packet-processing component 203. Each Virtual-Service-Module instance 200 also may have ports that describe its relation to other components and have interfaces to communicate with components external to the virtual network system. The ports are used by both the management component 201 and the flow setup component 202.
[0024] The management component 201 directs interfacing with the various management interfaces common to the components internal to the virtual system. The management component 201 also maintains any global information required. The management component 201 gathers information by communicating with external entities such as routers and authentication authorities. The management component 201 may dynamically configure the virtual service module 200.
[0025] The flow setup component 202 performs initial packet-processing, determining the packet path through the virtual network graph, and building an action list for the flow. Flow may be a particular stream of related packets. For example, the stream of data a server sends to a client over a particular TCP connection is a flow of related packets. [0026] The packet-processing component 203 is an abstract piece of the Virtual-Service- Module 200. The packet-processing component 203 may contain an action list of standard processing primitive instructions programmed into a hardware accelerator application specific integrated circuit. A Virtual-Service-Module that requires packet processing beyond what the standard primitive instructions in the packet-processing component 203 can accomplish would continue to process the packets in the flow set-up processing component 202. A Virtual-Service- Module that starts each related packet flow as this type of extended flow setup can bind an action list at any time, but in some cases the Virtual-Service-Module processes the entire related packet flow without ever switching to hardware assist.
[0027] In an embodiment, each Virtual-Service-Module 200 is a self-contained module of data and its associated processing software that has an archive file containing both executable code as well as metadata that integrates the service module with the network system. The executable code includes instructions to install and remove that instance of the Virtual-Service- Module 200. Further, the executable code includes instructions to configure that instance of the Virtual-Service-Module 200 with configuration information. As noted, each Virtual-Service- Module 200 may contain data and its associated processing software to model a discrete network element such as a firewall, a filter, a load balancer, a router, etc.
[0028] In an embodiment, a Virtual-Service-Module 200 belongs to an object class in which one or more instances of each Virtual-Service-Module 200 may exist. Objects may be independent program modules written in object-oriented programming languages. Objects are software components structured to plug into and work with each other at runtime without any prior linking or precompilation as a group. One or more instances of particular type of Virtual- Service-Module 200 may be created.
[0029] In an alternative embodiment, each VSM component may be contained in a single container application, just as long as the service module is modeled to represent a network element.
[0030] Referring to figure 1, For example, the class of Virtual-Service-Modules modeled to represent firewalls 132, 138 may have multiple instances of that Virtual-Service-Module plugged into multiple customers' virtual racks 120, 121 throughout the virtual graph 108. The classes of Virtual-Service-Modules modeled to represent network elements are created in hierarchies, and inheritance allows the knowledge in one class in a layer higher in the hierarchy to be passed down to another class lower in the hierarchy, such as an instance of a VSM firewall. [0031] Referring to figure 2, in an embodiment, Virtual-Service-Modules 200 may be packaged in separate binary images. The image contains an archive file of both executable code as well as metadata that integrates the Virtual-Service-Module 200 with the system. The meta data includes information that describes the various configuration parameters supported by the Virtual-Service-Module, versioning information, resources required, dependency information, and any specific commands required to configure the module through the command-line interface (CLI). Using this information, the network system can easily integrate the Virtual-Service- Module 200 without the user known what functionality is "built-in" to the base system and what has been added later. In an embodiment, extendable markup language (XML) may be used to format the meta data.
[0032] In an embodiment, even after a Virtual-Service-Module 200 has bound an action list, the flow set-up component 202 can handle exception conditions reported from the action list in the packet processing component 203 in order to handle the more complicated processing sometimes required for infrequent events. In an embodiment, an action list may be a list of processing primitive instructions that a Virtual-Service-Module wants applied to each packet in a given related packet flow. Processing primitive instructions may be a single, primitive instruction packet transformation operation. For example, decrementing the IP TTL field or recomputing the IP checksum field are each processing primitive instructions. A combined action list is the concatenation of each Virtual-Service-Module 's action list for all the nodes in a given sequential node list. A common action list is a global action list applied to all arriving packets. An optimized action list is the combined action list after it has been optimized. [0033] In an embodiment, a Virtual-Service-Module 200 may have three types of addressing perspectives.
[0034] Referring to figure 1, the most familiar addressing perspective is the router-like Virtual-Service-Module 124, 136 that performs "normal" routing functions. The other two Virtual-Service-Module addressing perspectives can be restricted to two ports, which means that no routing decisions will be required. These two addressing perspectives are the addressable bump and the anonymous bump that make forwarding decisions. For example, the firewall Virtual-Service-Module 132, 138 can be an anonymous bump that decides which packets to drop, but once a decision to forward the packet has been made, there is no choice as to which port the packet should be sent. An addressable bump may be, for example, a Virtual Private Network. [0035] Figure 3 illustrates an embodiment of a Virtual-Service-Module container architecture and the Virtual-Service-Module mapping to the physical layer. In an embodiment, the container program consists of two or more sub-programs. Each sub-program is programmed for a specific function such as a management container 302, a flow setup container 304, and a packet- processing container 306. The container architecture may use the three different types of containers 302, 304, 306 to manage the three individual components of a Virtual-Service- Module, the management component 308, a flow setup component 310, and a packet-processing component 312. In an embodiment, the management container 302, the flow setup container 304, and the packet-processing container 306 may be included as portions of the operating system software. The management component 308 may embed in the management container 302. The flow setup component 310 may embed in the flow setup container 304. The packet- processing component 312 may embed in the packet processing container 306. [0036] The management container 308 provides various common management interfaces such as SNMP, web, and CLI, and allows the Virtual-Service-Module to interact with that functionality. The flow setup container 304 wraps the Virtual-Service-Module flow setup component 310 and provides for the dispatching of new related packet flows to flow setup components. The flow setup container 304 provides the creation and optimization of action lists. The packet-processing container 306 manages the optimized combined processing list transferred from the flow setup module 310 on a per-flow basis.
[0037] A Virtual-Service-Module, such as Virtual-Service-Module 322, may interact with another Virtual-Service-Module though the container program. In an embodiment, no Virtual- Service-Module contains a direct object reference to another Virtual-Service-Module. This makes it much easier to alter the virtual network graph and upgrade Virtual-Service-Modules without having to worry about other Virtual-Service-Modules holding stale object references. Therefore, Virtual-Service-Modules can operate in total isolation without having to worry about what other Virtual-Service-Modules may exist in the chain and the various lifecycle changes those other Virtual-Service-Modules may be going through.
[0038] In an embodiment, the management container 302, flow setup container 304, and packet-processing container 306 implement various portions of a Virtual-Service-Module's Application Program Interface. The management container 302 provides API functions to install and remove a Virtual-Service-Module, to configure a Virtual-Service-Module with both box- wide and content-provider-specific configuration information, and to manage a Virtual-Service- Module. [0039] The flow setup container 304 provides API functions to dispatch new related packet flows, build and manage the creation of optimized processing lists, and the packet flow transfers to the packet-processing module, manipulate packet contents, and manipulate related packet flow state.
[0040] The packet-processing container 306 performs packet processing on the fast path and resides in the packet-processing physical implementation. The packet-processing container provides some of the services of the flow setup container, but eliminates most of the functions that deal with high-level issues such as Virtual-Service-Module configuration and lifecycle management. The packet-processing container 306 provides functions to manipulate packet contents, manipulate related packet flow state, and inform the flow setup container of flow termination, which is then passed on to the appropriate Virtual-Service-Module flow setup component 310.
[0041] In an embodiment, the management component 308, flow setup component 310, and packet-processing component 312 of the Virtual-Service-Module 322 may be embedded or linked into the container program. These components of the VSM 308, 310, 312 can be linked instead of embedded, in which case the container application does not physically hold the component of the VSM, but provides a pointer to it. If a change is made to a linked component of the VSM, all the documents that contain the same link are automatically updated the next time you open them. If these components 308, 310, 312 are embedded, then the container that contains a copy of that component. Changes made to that component of the VSM affect only the container program that contains that instance of the component. If a component of the VSM is linked, the document contains a pointer to the original file. When you change a linked component, you are changing the original, and all the programs that link to that component are automatically updated. The container program may provide common functions such as security and transaction support and delivers a consistent interface to the applications regardless of the type of server. The ultimate goal of objects is that it should not matter which source language they were programmed in or which computer on the network they are running in. Virtual- Service-Modules interoperate through the messages passed between the container program. [0042] Each of the Virtual-Service-Module components 308, 310, 312 may be mapped to a different physical circuit board 314, 316, 318. The physical layer of the virtual network system may have several types of circuit modules such as a Management module 314, a service processing module that includes a Flow processing module 316 as well as a packet processing module 318, and an I/O module. The management module 314 includes the switch fabric hardware. The switch fabric hardware consists of a data-passing board in the chassis. Each flow set up module 316 (FPM) may contain one or more flow processing engines. Each flow processing engine may include a General Purpose Processor and an application specific integrated circuit to process packeted information such as a packet-processing hardware accelerator. Each packet processing module 318 may contain one or more flow processing engines. Each flow processing engine is an addressable end point on the data passing hardware connecting board in the chassis. The input-output (I/O) module supports one or more external I/O ports via one or more VO engines.
[0043] The management component 308 of the Virtual-Service-Module can map to and run on the management module 314. The flow setup component 310 maps to and runs on a General- Purpose-Processor on one of the Flow-Processing-Engines. Packet processing may handled in the packet-processing hardware accelerator, with special cases handled via exceptions passed to the General-Purpose-Processor.
[0044] Figure 4 illustrates an embodiment of an individual network having a topology composed of virtual network elements and physical network elements. The first individual network 402 includes a virtual rack 419 housing customer A's virtual network elements. The virtual rack 419 couples via a port 416 to the customer A's network 418. Also, the virtual rack 419 couples via a second port 425 to a physical network element, such as a firewall 452. An SSL Virtual-Service-Module 426 of the individual network associated with customer A 402 receives packets from the system router Virtual-Service-Module 424. The SSL Virtual-Service-Module 426 forwards the packets to the physical firewall 452 via the second port 425. The physical firewall 452 forwards the packets via the second port 425 to a NAT Virtual-Service-Module 428. The NAT Virtual-Service-Module 428 routes the packets to the bridge Virtual-Service-Module 430. The packets exit the topology of the individual network associated with customer A 402 to the customer's network 418 via multiple ports 416.
[0045] In an embodiment, the physical layer contains one or more virtual rack processors. Each virtual rack processor manages the flow of data through the physical layer, allocates resources for each virtual rack 419, and performs high-speed packet processing to implement a particular service. Because the virtual rack 419 uses hardware-based resource management, the virtual rack 419 is more efficient, accurate, and secure than software-based schemes. The virtual rack processor subsystem's activities can be divided into three main categories, Queuing and high-speed processing, Managing general processing resources, and Dealing with the integrity and security of the virtual rack. [0046] In an embodiment, each virtual rack processor assigns multiple queues to each virtual rack 419 in the system. The virtual rack processor services these queues using a token bucket algorithm that ensures that each virtual rack receives its share of the VRP processing resources. The virtual rack processor manages the virtual rack queues in a very large memory area with large buffering capability. By allocating multiple queues per virtual rack, the virtual rack processor ensures that no one virtual rack 419 is able to consume all the available buffer memory at the expense of a second virtual rack 420. The token bucket logic assures that every virtual rack has fair access to the virtual rack processor processing unit.
[0047] As noted, if the virtual rack processor decides that a particular packet requires extensive high level processing, it forwards the packet to the general processing block for further attention and moves on to processing the next packet in its queues. Between the virtual rack processor and the general processing block, the virtual rack processor implements a second set of queuing logic. As with the first set of queues, each virtual rack 419-421 in the system is assigned queues in the second set. The virtual rack processor manages this second set of queues and forwards packets to the general processing block as required. This keeps the general processing block fed, and delivers the highest possible throughput. The virtual rack processor subsystem schedules the next packet for the general processing block to ensure that processing resources are distributed according to physical layer resource allocations. In this way, no one virtual rack 419- 421 can monopolize processing resources at the expense of the others. [0048] The virtual rack processor subsystem allocates a memory area for each virtual rack 419-421 in the system. The memory area stores packets and service state information associated with the particular virtual rack, such as virtual rack A 419. The system monitors each area closely for resource consumption. If a particular virtual rack, such as virtual rack A 419, encroaches on a physical layer memory allocation limit, it is not allowed to expand further at the expense of other virtual racks. This behavior ensures that no one virtual rack 419-421 can monopolize memory resources at the expense of the others.
[0049] The physical layer uses a hardware memory management unit (MMU) to create a protection domain for each virtual rack 419-421. When a service crashes, the protection domain isolates the impact to the particular virtual rack 419-421 where the service is located. When the system detects a crash, the protection domain associated with the virtual rack 419-421 is flushed, and the virtual rack 419-421 is automatically restarted. In this way, the system contains service faults to the virtual rack 419-421 where they originate, preventing them from propagating to other virtual racks 419-421 or affecting their processing. [0050] When working on a packet, the processing block first enters the protection domain associated with the virtual rack 419-421 to which the packet belongs. While in this context, the processing block can only access memory associated with the virtual rack 419-421, assuring the security of the system. Any attempt to access memory resources outside the protection domain is treated as a service crash — in which case the protection domain is flushed and the virtual rack 419-421 is restarted.
[0051] As noted above, each Virtual-Service-Module 424, 426, 428, 430 may be dynamically loaded or unloaded through a user interface of the management virtual rack 412. Multiple instances of the Virtual-Service-Modules may be loaded simultaneously, such as router Virtual- Service-Modules 424 and 436. Further, multiple instances of Virtual-Service-Modules may contain different versions. For example, router Virtual-Service-Module 424 may have different version than the router Virtual-Service-Module 436. Each Virtual-Service-Module can be changed or upgraded individually without disrupting other services of the other Virtual-Service- Modules.
[0052] Figure 5 A shows an exemplary block diagram illustrating an upgrade of a Virtual- Service-Module according to an embodiment of the invention. Referring to Figure 5A, in one embodiment, an initial configuration 501 of a topology processes a data flow through router Virtual-Service-Module 504, a firewall Virtual-Service-Module 505, a secure socket layer (SSL) Virtual-Service-Module version 1506, and a load balancer Virtual-Service-Module 507. When an upgrade request of SSL Virtual-Service-Module is received (e.g., through a user interface of the management virtual rack), another instance of SSL Virtual-Service-Module version II 508 is launched. Once the SSL Virtual-Service-Module version II 508 is launched, the system connect the SSL Virtual-Service-Module 508 to the firewall Virtual-Service-Module 505 through the edge 509 and to the load balancer Virtual-Service-Module 507 through the edge 510. Thus, the SSL Virtual-Service-Module version II 508 and the SSL Virtual-Service-Module version 1506 are running in parallel, as shown in configuration 502.
[0053] The system then directs any new flow data to the newly executed SSL Virtual- Service-Module version II 508. The SSL Virtual-Service-Module 508 processes the new data flow and transmit the data to the load balancer Virtual-Service-Module 507 thereafter. At the mean while, the system continue direct the existing data flow to the SSL Virtual-Service-Module version 1506. This parallel processing continues until certain conditions are satisfied. In one embodiment, the condition may be a pre-specified amount data of existing flow waiting for processing. In an alternative embodiment, the condition may be a pre-specified period of time. Anytime before this condition is reached, the upgrade can be aborted instantaneously through the user interface of the management virtual rack.
[0054] Once the conditions are satisfied, the system directs all of the traffics to the new SSL Virtual-Service-Module 508. Once the SSL Virtual-Service-Module 508 stabilizes, the system disconnects the edges 511 and 512 between the SSL Virtual-Service-Module 506 and the firewall Virtual-Service-Module 505 and load balancer Virtual-Service-Module 507 respectively. Thereafter, the SSL Virtual-Service-Module 506 is terminated and removed from the graph, as shown in configuration 503. As a result, SSL Virtual-Service-Module service has been upgraded dynamically and the services being provided originally by SSL Virtual-Service-Module 506 is not disrupted.
[0055] When the upgrade is aborted, the system directs all the new flow data to the old SSL Virtual-Service-Module version 1506. The system disconnects the edges 509 and 510. This takes the virtual rack to its original state before the upgrade was started. All the flows that started going through the SSL Virtual-Service-Module 508 are terminated by the system. The old flows that were going through the SSL Virtual-Service-Module version 1506 will continue to go through without any change.
[0056] Figure 5B shows a flowchart illustrating an exemplary method of upgrading a Virtual- Service-Module according to an embodiment of the invention. Li one embodiment, the method illustrates processing a request for changing a first node having a first service connecting with a second node and a third node in a network environment. The method includes dynamically launching a second service at the first node, connecting the second service with the second and the third nodes, directing requests for service to the second service, and terminating the first service. Li an alternative embodiment, the method further includes determining whether the requests for service come from a new session of data, transmitting the requests for service to the second service if the requests for service come from a new session of data, and transmitting the requests for service to the first service if the requests for service come from an existing session of data.
[0057] Referring to Figure 5B, when an upgrade request is received, at block 551, the system dynamically launches a new service (e.g., an instance of a Virtual-Service-Module with upgraded version), while the existing service (e.g., the existing Virtual-Service-Module needed to be upgraded) still processing the data flow from a first node to a second node. At block 552, the system connects the new Virtual-Service-Module to the first and second nodes. At block 553, the system then directs the new flow of data to the new Virtual-Service-Module, while directing the existing flow of data to the existing Virtual-Service-Module for processing. Thus the new and existing flows of data are processed in parallel by the new and existing Virtual-Service- Modules respectively. At block 554, the system checks whether a pre-specified condition has been satisfied. In one embodiment, the condition may be an amount of existing flow of data remains to be processed. In an alternative embodiment, the condition may be a period of time remained. Other conditions may be utilized. The parallel processes continue until the condition is satisfied. Once the condition is satisfied, at block 555, the system directs all data flows to the new Virtual-Service-Module and terminates the existing Virtual-Service-Module at block 556. [0058] Thus, a new instance of the service module having different functionality than the existing instance of the service module may load during program execution, specifically, long after the initial start-up phase. The new instance of the service module to mirror the network routing path of the existing instance during the installation of the new instance so that the addition of functionality without causing downtime for any other components. [0059] In an embodiment, in block 557 the system checks to see if the change is aborted. In block 558, if the change is aborted then the system directs all new data flow to the old service. The system terminates the new flow through the new service. Also the system continues the old flow through the old service. In block 559, the system then terminates the new service. [0060] Figure 6A shows an exemplary block diagram illustrating changes of a topology of a virtual network system according to an embodiment of the invention. Referring to Figure 6A, in one embodiment, an initial configuration 601 of a topology processes a data flow through router VSM 604, a firewall VSM 605, a secure socket layer (SSL) VSM 606, and a load balancer VSM 607. When a change request (e.g., adding a VPN VSM to the graph) is received (e.g., through a user interface of the management virtual rack), an instance of VPN VSM 608 is launched. Once the VPN VSM 608 is launched, the system connect the VPN VSM 608 to the firewall VSM 605 through the edge 609 and to the load balancer VSM 607 through the edge 610. Thus, the VPN VSM 608 and the edge 611 connecting VSM 606 and VSM 605 are running in parallel, as shown in configuration 602.
[0061] The system then directs any new flow data to the newly executed VPN VSM 608. The VPN VSM 608 processes the new data flow and transmits the data to the SSL VSM 606 thereafter. At the mean while, the system continues direct the existing data flow to the SSL VSM 606 through the edge 611. This parallel processing continues until certain conditions are satisfied. Li one embodiment, the condition may be a pre-specified amount data of existing flow waiting processing. Li an alternative embodiment, the condition may be a pre-specified period of time.
[0062] In an embodiment, the change of the topology can be aborted anytime before the conditions to commit are satisfied. If the conditions are not met first, the configuration looks like 603. If the change is aborted before the conditions are met, it is reverted back to the original configuration 601.
[0063] Once the conditions are satisfied, the system directs all of the traffic to the new VPN VSM 608. Once system clears all old related packets of flow from the VPN VSM 608, the system disconnects the edges 611 between the SSL VSM 606 and the firewall VSM 605. As a result, VPN VSM service has been added to the graph dynamically and the services being provided originally by the edge 611 is not disrupted.
[0064] If the change is aborted, the system directs all of the new flow data to SSL Virtual- Service-Module 606 through the edge 611. The system terminates any flow going through the edge 609, the VPN Virtual-Service-Module 608, and the edge 610. The system continues to direct the existing data flow to the SSL VSM 606 through the edge 611. The system disconnects the edges 609 and 610, and the VPN Virtual-Service-Module 608. Thus restoring the original topology.
[0065] Figure 6B shows a flowchart illustrating an exemplary method of changing a topology according to an embodiment of the invention. In one embodiment, the method illustrates processing a request for changing a topology having a direct connection between a first node and a second node in a network environment. The method includes dynamically launching a new service, the service intended to be added between the first and second nodes, connecting the new service with the first and the second nodes, directing requests for service to the new service from the first node and thereafter transmit the requests to the second node, and terminating the direct connection between the first and second node. Li an alternative embodiment, the method further includes determining whether the requests for service come from a new session of data, transmitting the requests for service to the new service if the requests for service come from a new session of data, and transmitting the requests for service to the direct connection between the first and second nodes if the requests for service come from an existing session of data. [0066] Referring to Figure 6B, when request is received, at block 651, the system dynamically launches a new service, the new service is intended to be added between a first node and a second node, the first and the second nodes are connected directly to each other through an edge. After the new service has been launched, at block 652, the system connects the new service to the first and the second nodes. The system then directs the new data flow to the new service from the first node, the new service processes new data flow and transmits the data to the second node.
[0067] At the mean while, the first node continue to transmit the existing data flow to the second node directly through the edge directly connecting with the first and the second nodes. These parallel processing continues until certain conditions are satisfied checked by the system at block 654. If the conditions are satisfied, at block 655 the system instructs the first node transmit all data flows to the new service, the new service processes the data and transmits to the second node. Once the new service is up and running, at block 656, the system disconnects the edge directly connecting the first and the second nodes.
[0068] In an embodiment, in block 657 the system checks to see if the change is aborted. Li block 658, if the change is aborted then the system causes the first node to transmit all data to the second node. In block 659, the system then disconnects the first service node. [0069] Figure 7A shows an exemplary block diagram illustrating changes of a topology of a virtual network system according to an embodiment of the invention. Referring to Figure 7 A, in one embodiment, an initial configuration 701 of a topology processes a data flow through router VSM 704, a firewall VSM 705, a VPN VSM 706, and a load balancer VSM 707. When a change request (e.g., deleting the VPN VSM 706 from the graph) is received (e.g., through a user interface of the management virtual rack), an edge 708 is created to connect the firewall VSM 705 and the load balancer VSM 707.
[0070] Once the edge 708 is created and connected, the system instructs the firewall VSM 705 to transmit any new data flow to the load balancer VSM 707 directly through the edge 708, while the existing data flow is transmitted by the firewall VSM 705 to the load balancer VSM 707 through the VPN VSM 706. Thus, the edge 708 and the VPN VSM 706 are running in parallel, as shown in configuration 602. This parallel processing continues until certain conditions are satisfied. Li one embodiment, the condition may be a pre-specified amount data of existing flow waiting processing. In an alternative embodiment, the condition may be a pre- specified period of time.
[0071] In an embodiment, as described above, if a change is aborted redirects the new flow of data packets and continues the existing flow of data packets.
[0072] Once the conditions are satisfied, the system directs all of the traffics from the firewall VSM 705 directly to the load balancer VSM 707 through the edge 708. Once the data processing of the edge 708 stabilizes, the system disconnects the edges 709 and 710 between the VPN VSM 706 and the firewall VSM 705 and the load balancer VSM 707. Thereafter, the VPN VSM 706 is terminated and removed from the graph. As a result, VPN VSM service has been deleted from the graph dynamically and the services being provided originally by the VPN VSM 706 is not disrupted.
[0073] Figure 7B shows a flowchart illustrating an exemplary method of changing a topology according to an embodiment of the invention. L one embodiment, the method illustrates processing a request for changing a topology having a first node, a second node, and a third node, the first node being directly connected to the second node and the second node being directly connected to the third node. The method includes dynamically connecting the first and third nodes, directing requests for service directly from the first node to the second node, and terminating the second node. Li an alternative embodiment, the method further includes determining whether the requests for service come from a new session of data, transmitting the requests for service directly from the first node to the second node, if the requests for service come from a new session of data, and transmitting the requests for service from the first node to the second node and from second node to the third node, if the requests for service come from an existing session of data.
[0074] Referring to Figure 7B, when request is received, at block 751, the system dynamically connects a first node and a third node, wherein the first and the third node are connect through a second node in between. Once the connection between the first and the third nodes are created, at block 752, the system directs the new data flow to the direct connection between the first and third nodes. At the mean while, the second node is still processing the existing data flow received from the first node and thereafter transmitting the data to the third node. This parallel processing continues until a set of conditions is satisfied at block 753. Upon which, at block 754, the system directs all data flows from the first node directly to the third node without going through the second node. At block 755, the second node is terminated and removed from the graph, since it is no longer needed.
[0075] Li an embodiment, in block 757 the system checks to see if the change is aborted. In block 758, if the change is aborted then the system directs all the new data flow from the first node to the second node. Also, the system terminates any remaining flow going between the first node and third node. In block 759, the system deletes the edge connecting the first node and third node.
[0076] In one embodiment, the software used to facilitate the algorithms can be embodied onto a computer-readable medium. A computer -readable medium includes any mechanism that provides (e.g., stores and/or transmits) information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; DVD's, electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, EPROMs, EEPROMs, FLASH, magnetic or optical cards, or any type of media suitable for storing electronic instructions. Slower mediums could be cached to a faster, more practical, medium.
[0077] Some portions of the detailed descriptions above are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. [0078] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussions, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers, or other such information storage, transmission or display devices.
[0079] While some specific embodiments of the invention have been shown the invention is not to be limited to these embodiments. The invention is to be understood as not limited by the specific embodiments described herein, but only by scope of the appended claims.

Claims

CLAIMSWhat is claimed is:We claim:
1. An apparatus, comprising: a service module modeled to represent a network element that performs one or more functions to process a packet in a network system, the service module embedded in a container program, the service module being a self-contained module of data and its associated processing software that has an archive file containing both executable code as well as metadata that integrates the service module with the network system.
2. The apparatus of claim 1, wherein the service module comprises a high-level abstraction composed of multiple sub-components, the sub-components include: a management component to interface with components internal to a virtual network graph; a packet-processing component to determine a path of a packet through the virtual network graph; and a flow set-up component to process packets beyond what instructions in the packet- processing component can accomplish.
3. The apparatus of claim 1, wherein the service module belongs to an object class and one or more instances of the service module exist, a first instance of the service module having different versioning information than a second instance of the service module.
4. The apparatus of claim 1, wherein the network element is one of a group consisting of a router, an Ethernet switch, a virtual private network, a firewall, a load balancer, a bridge, and a network address translator.
5. The apparatus of claim 1, wherein the meta data includes information that describes the various configuration parameters supported by the service module and any specific commands required to configure the service module through a command-line interface.
6. The apparatus of claim 1, wherein the container program to provide a common environment for a first service module to interact with a second service module.
7. The apparatus of claim 1, wherein the container program comprises an operating system.
8. The apparatus of claim 1, further comprising: a first service module embeds in the container program; a second service module embeds in the container program, the second service module to communicate information with the first service module via the container program without a direct object reference to the first service module.
9. The apparatus of claim 1, wherein the executable code to include instructions to install and remove the service module, as well as instructions to configure the service module with configuration information.
10. The apparatus of claim 1, wherein the service module is mapped to physical processing power and memory capacity dedicated to that service module.
11. The apparatus of claim 1, wherein the service module is contained in a computer readable medium.
12. A network system, comprising: a virtual graph composed of a plurality individual networks; a first individual network associated with a first user, the first individual network having processing and memory resources dedicated to the first individual network; and a second individual network associated with a second user, the second individual network having processing and memory resources dedicated to the second individual network, wherein the processing and memory resources dedicated for the first individual network being independent from the processing and memory resources dedicated to the second individual network.
13. The network system of claim 12, further comprising: two or more service modules included in a topology of the first individual network, a first service module modeled to represent a network element, the two or more service modules arrangeable in the first individual network in an arbitrary topology.
14. The network system of claim 12, wherein the first individual network includes a first service module modeled to represent a network element, the second individual network includes a second service module modeled to represent a network element, the topology of the first individual network being composed of different network elements than included in the topology of the second individual network.
15. The network system of claim 12, wherein the first individual network maps to a first virtual address space within a global domain housing all of the virtual address spaces and the second individual network maps to a second virtual address space within the global domain housing all of the virtual address spaces.
16. The network system of claim 12, wherein the first individual network includes a first service module modeled to represent a network element, a new instance of the first service module having different functionality than the existing instance of the first service module to dynamically load during program execution.
17. The network system of claim 16, wherein the new instance to mirror the network routing path of the existing instance during the installation of the new instance so that the addition of functionality does not cause downtime for any other components.
18. The network system of claim 12, wherein the first individual network includes a first service module modeled to represent a network element, a first instance of the first service module being embedded in a container program, a second instance of the service module being embedded in the container program to allow multiple instances of the same service module modeled to represent a particular type of network element to be upgraded independently.
19. The network system of claim 12, further comprising: a resource management circuit employing a token bucket algorithm to ensure that each individual network receives processing and memory dedicated to that individual network.
20. The network system of claim 12, wherein the topology of the first individual network includes a first service module modeled to represent a network element and a physical network element external to the virtual graph.
21. A network system, comprising: a virtual graph composed of a plurality individual networks; a first individual network associated with a first user, the first individual network including a first plurality of service modules modeled to be representing a first set of network elements; a second individual network associated with a second user, the second individual network including a second plurality of service modules modeled to be representing a second set of network elements, wherein the second set of network element differs in type of network elements included in the second individual network and topological order of the network elements in the second individual network than the first set of network elements.
22. The network system of claim 21, wherein the first plurality of service modules includes a first service module embedded in a container program, the first service module being a self- contained module of data and its associated processing software that has an archive file containing both executable code as well as metadata that integrates the service module with the network system.
23. The network system of claim 21, wherein the first individual network has a unique virtual address space, dedicated processing power and dedicated memory to make the first individual network logically and physically distinct from the second individual network.
24. The network system of claim 23, wherein the dedicated processing power employs a token bucket algorithm.
25. The network system of claim 21, wherein the first plurality of service modules includes a first service module, the network system to load, remove, configure or modify the first service module during program execution without a packet flow disruption.
26. The network system of claim 21, wherein the virtual graph composed of a plurality individual networks is hosted on a single computing machine.
27. The network system of claim 26, wherein the first individual network associated with the first user also includes a physical network element external to the single computing machine.
28. The apparatus of claim 1, further comprising: a physical layer in the network system, the physical layer having processing power and memory space dedicated to the service module.
29. The network system of claim 21, wherein the virtual graph composed of a plurality individual networks is hosted on a multiple computing machines connected by a network.
30. The network system of claim 29, wherein the first individual network associated with the first user also includes a physical network element external to the network connecting the multiple computing machines.
31. An apparatus, comprising: a computer readable medium storing a software module modeled to represent a network element that performs one or more functions to process a packet in a network system, the software module consisting of a high-level abstraction composed of multiple sub-components, wherein the sub-components include a management component to interface with components internal to a virtual network graph; a packet-processing component to determine a path of a packet through the virtual network graph; and a flow set-up component to process packets beyond what instructions in the packet- processing component can accomplish.
32. The appaiatus of claim 31, wherein the software module being a self-contained module of data and its associated processing software that has an archive file containing both executable code as well as metadata that integrates the software module with the network system.
PCT/US2003/008272 2002-04-19 2003-03-14 A network system having a virtual-service-module WO2003090108A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP03746923A EP1499991A4 (en) 2002-04-19 2003-03-14 A network system having a virtual-service-module
JP2003586783A JP2005523621A (en) 2002-04-19 2003-03-14 Network system with virtual service module
AU2003225847A AU2003225847A1 (en) 2002-04-19 2003-03-14 A network system having a virtual-service-module
CA002483209A CA2483209A1 (en) 2002-04-19 2003-03-14 A network system having a virtual-service-module

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/126,300 US7197553B2 (en) 2002-04-19 2002-04-19 Network system having a virtual-service-module
US10/126,300 2002-04-19

Publications (1)

Publication Number Publication Date
WO2003090108A1 true WO2003090108A1 (en) 2003-10-30

Family

ID=29214995

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2003/008272 WO2003090108A1 (en) 2002-04-19 2003-03-14 A network system having a virtual-service-module

Country Status (7)

Country Link
US (1) US7197553B2 (en)
EP (1) EP1499991A4 (en)
JP (1) JP2005523621A (en)
CN (1) CN100568216C (en)
AU (1) AU2003225847A1 (en)
CA (1) CA2483209A1 (en)
WO (1) WO2003090108A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100488153C (en) * 2006-04-06 2009-05-13 中国科学院计算技术研究所 Virtual network service deriving and using method and device
CN107528714A (en) * 2016-06-22 2017-12-29 中兴通讯股份有限公司 script processing method, device, system and router

Families Citing this family (103)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7111072B1 (en) 2000-09-13 2006-09-19 Cosine Communications, Inc. Packet routing system and method
US7487232B1 (en) 2000-09-13 2009-02-03 Fortinet, Inc. Switch management system and method
US7272643B1 (en) 2000-09-13 2007-09-18 Fortinet, Inc. System and method for managing and provisioning virtual routers
US7574495B1 (en) 2000-09-13 2009-08-11 Fortinet, Inc. System and method for managing interworking communications protocols
US8250357B2 (en) 2000-09-13 2012-08-21 Fortinet, Inc. Tunnel interface for securing traffic over a network
US20050198379A1 (en) 2001-06-13 2005-09-08 Citrix Systems, Inc. Automatically reconnecting a client across reliable and persistent communication sessions
US7181547B1 (en) 2001-06-28 2007-02-20 Fortinet, Inc. Identifying nodes in a ring network
US7246178B2 (en) * 2002-05-07 2007-07-17 Nortel Networks Limited Methods and systems for changing a topology of a network
US7376125B1 (en) 2002-06-04 2008-05-20 Fortinet, Inc. Service processing switch
US7203192B2 (en) 2002-06-04 2007-04-10 Fortinet, Inc. Network packet steering
US7161904B2 (en) * 2002-06-04 2007-01-09 Fortinet, Inc. System and method for hierarchical metering in a virtual router based network switch
US7177311B1 (en) * 2002-06-04 2007-02-13 Fortinet, Inc. System and method for routing traffic through a virtual router-based network switch
US7116665B2 (en) 2002-06-04 2006-10-03 Fortinet, Inc. Methods and systems for a distributed provider edge
US7096383B2 (en) 2002-08-29 2006-08-22 Cosine Communications, Inc. System and method for virtual router failover in a network routing system
US7266120B2 (en) 2002-11-18 2007-09-04 Fortinet, Inc. System and method for hardware accelerated packet multicast in a virtual routing system
US7720095B2 (en) 2003-08-27 2010-05-18 Fortinet, Inc. Heterogeneous media packet bridging
US7978716B2 (en) 2003-11-24 2011-07-12 Citrix Systems, Inc. Systems and methods for providing a VPN solution
US8495305B2 (en) 2004-06-30 2013-07-23 Citrix Systems, Inc. Method and device for performing caching of dynamically generated objects in a data communication network
US7757074B2 (en) 2004-06-30 2010-07-13 Citrix Application Networking, Llc System and method for establishing a virtual private network
US8739274B2 (en) * 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network
CN101199187A (en) 2004-07-23 2008-06-11 茨特里克斯系统公司 A method and systems for securing remote access to private networks
US7808906B2 (en) 2004-07-23 2010-10-05 Citrix Systems, Inc. Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgements
KR20070083482A (en) 2004-08-13 2007-08-24 사이트릭스 시스템스, 인크. A method for maintaining transaction integrity across multiple remote access servers
US7499419B2 (en) 2004-09-24 2009-03-03 Fortinet, Inc. Scalable IP-services enabled multicast forwarding with efficient resource utilization
US7808904B2 (en) * 2004-11-18 2010-10-05 Fortinet, Inc. Method and apparatus for managing subscriber profiles
US8549149B2 (en) 2004-12-30 2013-10-01 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing
US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
US7810089B2 (en) * 2004-12-30 2010-10-05 Citrix Systems, Inc. Systems and methods for automatic installation and execution of a client-side acceleration program
US8700695B2 (en) 2004-12-30 2014-04-15 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP pooling
US8706877B2 (en) 2004-12-30 2014-04-22 Citrix Systems, Inc. Systems and methods for providing client-side dynamic redirection to bypass an intermediary
US8255456B2 (en) 2005-12-30 2012-08-28 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
KR20070104566A (en) 2005-01-24 2007-10-26 사이트릭스 시스템스, 인크. Systems and methods for performing caching of dynamically generated objects in a network
US9946585B1 (en) * 2005-06-30 2018-04-17 Oracle America, Inc. System and method for asset module isolation
US8949364B2 (en) * 2005-09-15 2015-02-03 Ca, Inc. Apparatus, method and system for rapid delivery of distributed applications
US8301839B2 (en) 2005-12-30 2012-10-30 Citrix Systems, Inc. System and method for performing granular invalidation of cached dynamically generated objects in a data communication network
US7921184B2 (en) 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network
US20070239505A1 (en) * 2006-03-30 2007-10-11 Microsoft Corporation Abstract execution model for a continuation-based meta-runtime
US8327656B2 (en) 2006-08-15 2012-12-11 American Power Conversion Corporation Method and apparatus for cooling
US9568206B2 (en) 2006-08-15 2017-02-14 Schneider Electric It Corporation Method and apparatus for cooling
US8322155B2 (en) 2006-08-15 2012-12-04 American Power Conversion Corporation Method and apparatus for cooling
US7681404B2 (en) 2006-12-18 2010-03-23 American Power Conversion Corporation Modular ice storage for uninterruptible chilled water
US8425287B2 (en) 2007-01-23 2013-04-23 Schneider Electric It Corporation In-row air containment and cooling system and method
US7739690B2 (en) * 2007-04-26 2010-06-15 Microsoft Corporation Meta-container for model-based distributed applications
DK2147585T3 (en) 2007-05-15 2017-01-16 Schneider Electric It Corp PROCEDURE AND SYSTEM FOR HANDLING EQUIPMENT AND COOLING
US8910234B2 (en) * 2007-08-21 2014-12-09 Schneider Electric It Corporation System and method for enforcing network device provisioning policy
US20090052444A1 (en) * 2007-08-24 2009-02-26 At&T Bls Intellectual Property, Inc. Methods, systems, and computer program products for providing multi-service communication networks and related core networks
US8549347B1 (en) * 2010-12-20 2013-10-01 Amazon Technologies, Inc. Techniques for network replication
US8180616B1 (en) * 2008-12-18 2012-05-15 Xilinx, Inc. Component tracing in a network packet processing device
US9009214B2 (en) 2008-12-23 2015-04-14 International Business Machines Corporation Management of process-to-process inter-cluster communication requests
US9098354B2 (en) * 2008-12-23 2015-08-04 International Business Machines Corporation Management of application to I/O device communication requests between data processing systems
US8370855B2 (en) * 2008-12-23 2013-02-05 International Business Machines Corporation Management of process-to-process intra-cluster communication requests
US8521895B2 (en) * 2008-12-23 2013-08-27 International Business Machines Corporation Management of application to application communication requests between data processing systems
US8240473B2 (en) * 2008-12-23 2012-08-14 Honda Motor Co., Ltd. Headliner packaging system with hinged clamp
US8499029B1 (en) 2008-12-23 2013-07-30 International Business Machines Corporation Management of process-to-process communication requests
US9519517B2 (en) * 2009-02-13 2016-12-13 Schneider Electtic It Corporation Data center control
US9778718B2 (en) 2009-02-13 2017-10-03 Schneider Electric It Corporation Power supply and data center control
US8560677B2 (en) * 2009-02-13 2013-10-15 Schneider Electric It Corporation Data center control
US20100299362A1 (en) * 2009-05-24 2010-11-25 Roger Frederick Osmond Method for controlling access to data containers in a computer system
US9015198B2 (en) * 2009-05-26 2015-04-21 Pi-Coral, Inc. Method and apparatus for large scale data storage
US8339994B2 (en) * 2009-08-27 2012-12-25 Brocade Communications Systems, Inc. Defining an optimal topology for a group of logical switches
CN104065555B (en) 2009-09-24 2018-09-18 日本电气株式会社 Communication identification method between communication identification system and virtual server between virtual server
EP2487843B1 (en) 2009-10-07 2020-04-22 Nec Corporation Information system, control server, virtual network management method, and program
US8909781B2 (en) * 2010-05-24 2014-12-09 Pi-Coral, Inc. Virtual access to network services
US8724645B2 (en) 2010-09-28 2014-05-13 Microsoft Corporation Performing computations in a distributed infrastructure
US8516032B2 (en) * 2010-09-28 2013-08-20 Microsoft Corporation Performing computations in a distributed infrastructure
CN104040459B (en) 2011-12-22 2017-11-14 施耐德电气It公司 For the system and method for the energy stores demand for reducing data center
CN104137105B (en) 2011-12-22 2017-07-11 施耐德电气It公司 Impact analysis on temporal event to the temperature in data center
AU2011383606A1 (en) 2011-12-22 2014-07-17 Schneider Electric It Corporation System and method for prediction of temperature values in an electronics system
US9952909B2 (en) * 2012-06-20 2018-04-24 Paypal, Inc. Multiple service classes in a shared cloud
GB2503463A (en) 2012-06-27 2014-01-01 Ibm Overriding abstract resource manager methods to provide resources to implement nodes in a service definition
US10601653B2 (en) 2012-07-06 2020-03-24 Cradlepoint, Inc. Implicit traffic engineering
US9992062B1 (en) 2012-07-06 2018-06-05 Cradlepoint, Inc. Implicit traffic engineering
US10135677B1 (en) 2012-07-06 2018-11-20 Cradlepoint, Inc. Deployment of network-related features over cloud network
US10110417B1 (en) 2012-07-06 2018-10-23 Cradlepoint, Inc. Private networks overlaid on cloud infrastructure
US10880162B1 (en) 2012-07-06 2020-12-29 Cradlepoint, Inc. Linking logical broadcast domains
US10177957B1 (en) * 2012-07-06 2019-01-08 Cradlepoint, Inc. Connecting a cloud network to the internet
US9118495B1 (en) 2012-07-06 2015-08-25 Pertino, Inc. Communication between broadcast domains
US10560343B1 (en) 2012-07-06 2020-02-11 Cradlepoint, Inc. People centric management of cloud networks via GUI
US9929919B2 (en) * 2012-10-30 2018-03-27 Futurewei Technologies, Inc. System and method for virtual network abstraction and switching
US10142406B2 (en) 2013-03-11 2018-11-27 Amazon Technologies, Inc. Automated data center selection
US10313345B2 (en) 2013-03-11 2019-06-04 Amazon Technologies, Inc. Application marketplace for virtual desktops
US9002982B2 (en) 2013-03-11 2015-04-07 Amazon Technologies, Inc. Automated desktop placement
US9148350B1 (en) 2013-03-11 2015-09-29 Amazon Technologies, Inc. Automated data synchronization
US9973375B2 (en) * 2013-04-22 2018-05-15 Cisco Technology, Inc. App store portal providing point-and-click deployment of third-party virtualized network functions
US10686646B1 (en) 2013-06-26 2020-06-16 Amazon Technologies, Inc. Management of computing sessions
US10623243B2 (en) * 2013-06-26 2020-04-14 Amazon Technologies, Inc. Management of computing sessions
US9311123B2 (en) * 2013-07-02 2016-04-12 Hillstone Networks, Corp. Distributed virtual security appliance and flow-based forwarding system using virtual machines
CN104579732B (en) * 2013-10-21 2018-06-26 华为技术有限公司 Virtualize management method, the device and system of network function network element
IN2013CH05013A (en) 2013-11-07 2015-05-08 Schneider Electric It Corp
US9298485B2 (en) 2013-11-19 2016-03-29 International Business Machines Corporation Maintaining virtual machines for cloud-based operators in a streaming application in a ready state
KR101979362B1 (en) * 2014-01-29 2019-08-28 후아웨이 테크놀러지 컴퍼니 리미티드 Method for upgrading virtualized network function and network function virtualization orchestrator
CN105282765A (en) * 2014-06-30 2016-01-27 中兴通讯股份有限公司 Method and equipment for managing configuration information, and network element management system
US9866408B2 (en) 2014-12-12 2018-01-09 Oracle International Corporation Methods, systems, and computer readable media for configuring a flow interface on a network routing element
US10230589B2 (en) * 2014-12-12 2019-03-12 Oracle International Corporation Methods, systems, and computer readable media for configuring service networks
CN106201566B (en) * 2015-05-07 2019-08-23 阿里巴巴集团控股有限公司 Benefit wins the hot upgrade method of big special software and equipment
US9843499B2 (en) * 2015-07-27 2017-12-12 General Motors Llc Distributed database server network and maintenance process
US10261782B2 (en) * 2015-12-18 2019-04-16 Amazon Technologies, Inc. Software container registry service
US10283249B2 (en) 2016-09-30 2019-05-07 International Business Machines Corporation Method for fabricating a magnetic material stack
CN107967140B (en) 2016-10-18 2021-08-03 华为技术有限公司 Software modification initiating method, metadata publishing method and device
CN106789304B (en) * 2016-12-29 2019-12-06 杭州迪普科技股份有限公司 Network equipment configuration synchronization method and device
CN111682956B (en) * 2020-04-28 2023-07-28 平安银行股份有限公司 Network upgrading method, device, server and readable storage medium
CN113552813B (en) * 2021-09-18 2021-12-24 北京翔东智能科技有限公司 Intelligent household electrical appliance networking control system
CN117176781A (en) * 2023-11-01 2023-12-05 北京融为科技有限公司 Point-to-point networking method and device

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020069369A1 (en) * 2000-07-05 2002-06-06 Tremain Geoffrey Donald Method and apparatus for providing computer services

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB8817288D0 (en) 1988-07-20 1988-08-24 Racal Milgo Ltd Methods of & networks for information communication
US5577028A (en) 1990-08-31 1996-11-19 Fujitsu Limited Routing system using a neural network
US5481735A (en) 1992-12-28 1996-01-02 Apple Computer, Inc. Method for modifying packets that meet a particular criteria as the packets pass between two layers in a network
SE9402059D0 (en) 1994-06-13 1994-06-13 Ellemtel Utvecklings Ab Methods and apparatus for telecommunications
US5526414A (en) 1994-10-26 1996-06-11 Northern Telecom Limited Dynamically controlled routing using virtual nodes
US5550816A (en) 1994-12-29 1996-08-27 Storage Technology Corporation Method and apparatus for virtual switching
US5598410A (en) 1994-12-29 1997-01-28 Storage Technology Corporation Method and apparatus for accelerated packet processing
US5583862A (en) 1995-03-28 1996-12-10 Bay Networks, Inc. Method and apparatus for routing for virtual networks
US5592622A (en) 1995-05-10 1997-01-07 3Com Corporation Network intermediate system with message passing architecture
US5636371A (en) 1995-06-07 1997-06-03 Bull Hn Information Systems Inc. Virtual network mechanism to access well known port application programs running on a single host system
US5764736A (en) 1995-07-20 1998-06-09 National Semiconductor Corporation Method for switching between a data communication session and a voice communication session
US6055618A (en) 1995-10-31 2000-04-25 Cray Research, Inc. Virtual maintenance network in multiprocessing system having a non-flow controlled virtual maintenance channel
US5684800A (en) 1995-11-15 1997-11-04 Cabletron Systems, Inc. Method for establishing restricted broadcast groups in a switched network
US5805587A (en) 1995-11-27 1998-09-08 At&T Corp. Call notification feature for a telephone line connected to the internet
JP3609562B2 (en) 1996-11-15 2005-01-12 株式会社日立製作所 Network management system
US5781624A (en) 1996-02-16 1998-07-14 Lucent Technologies Inc. Method for sharing network resources by virtual partitioning
US5809025A (en) 1996-03-15 1998-09-15 Motorola, Inc. Virtual path-based static routing
US6085238A (en) 1996-04-23 2000-07-04 Matsushita Electric Works, Ltd. Virtual LAN system
US6108689A (en) 1996-10-11 2000-08-22 International Business Machines Corporation Method and system for processing messages in a distributed computing environment
JP3688408B2 (en) 1996-10-29 2005-08-31 株式会社東芝 Packet transfer control method and node device
US5917899A (en) * 1996-12-17 1999-06-29 Ameritech Corporation Method of connecting a plurality of virtual networks
US6172990B1 (en) 1997-06-19 2001-01-09 Xaqti Corporation Media access control micro-RISC stream processor and method for implementing the same
US6178453B1 (en) 1997-02-18 2001-01-23 Netspeak Corporation Virtual circuit switching architecture
US5852607A (en) 1997-02-26 1998-12-22 Cisco Technology, Inc. Addressing mechanism for multiple look-up tables
US6178183B1 (en) 1997-05-21 2001-01-23 International Business Machines Corporation Method and apparatus for receiving conventional telephone calls while connected to the internet
US5918074A (en) 1997-07-25 1999-06-29 Neonet Llc System architecture for and method of dual path data processing and management of packets and/or cells and the like
US6069895A (en) 1997-08-29 2000-05-30 Nortel Networks Corporation Distributed route server
US6041058A (en) 1997-09-11 2000-03-21 3Com Corporation Hardware filtering method and apparatus
US6658480B2 (en) 1997-10-14 2003-12-02 Alacritech, Inc. Intelligent network interface system and method for accelerated protocol processing
US6741693B1 (en) * 2000-06-22 2004-05-25 Sbc Properties, L.P. Method of operating a virtual private network
US6101181A (en) 1997-11-17 2000-08-08 Cray Research Inc. Virtual channel assignment in large torus systems
US6047330A (en) 1998-01-20 2000-04-04 Netscape Communications Corporation Virtual router discovery system
US6104962A (en) 1998-03-26 2000-08-15 Rockwell Technologies, Llc System for and method of allocating processing tasks of a control program configured to control a distributed control system
US6377571B1 (en) 1998-04-23 2002-04-23 3Com Corporation Virtual modem for dialout clients in virtual private network
US6046979A (en) 1998-05-04 2000-04-04 Cabletron Systems, Inc. Method and apparatus for controlling the flow of variable-length packets through a multiport switch
US6212560B1 (en) 1998-05-08 2001-04-03 Compaq Computer Corporation Dynamic proxy server
US6092178A (en) * 1998-09-03 2000-07-18 Sun Microsystems, Inc. System for responding to a resource request
US6909700B1 (en) * 1998-11-24 2005-06-21 Lucent Technologies Inc. Network topology optimization methods and apparatus for designing IP networks with performance guarantees
US6766348B1 (en) * 1999-08-03 2004-07-20 Worldcom, Inc. Method and system for load-balanced data exchange in distributed network-based resource allocation
US6665701B1 (en) * 1999-08-03 2003-12-16 Worldcom, Inc. Method and system for contention controlled data exchange in a distributed network-based resource allocation
US7403980B2 (en) * 2000-11-08 2008-07-22 Sri International Methods and apparatus for scalable, distributed management of virtual private networks
US20030179775A1 (en) * 2002-03-20 2003-09-25 Carolan Jason T. Service delivery network system and method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020069369A1 (en) * 2000-07-05 2002-06-06 Tremain Geoffrey Donald Method and apparatus for providing computer services

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"Inkra 4000 virtual service switch architecture", INKRA NETWORKS, 18 July 2002 (2002-07-18), pages 1 - 12, XP002970845 *
"Inkra Hardwall: A technology overview", INKRA NETWORKS, February 2002 (2002-02-01), pages 1 - 8, XP002970844 *
"New data center architecture from Inkra Networks enables dedicated services with shared economics", INKRA NETWORKS (PRESS RELEASE), 19 February 2002 (2002-02-19), pages 1 - 4, XP002970843, Retrieved from the Internet <URL:www.inkra.com> *
"New data center architecture scales multi-tier enterprise applications while slashing data center cost and complexity", INKRA NETWORKS (PRESS RELEASE), 19 February 2002 (2002-02-19), pages 1 - 2, XP002970847, Retrieved from the Internet <URL:www.inkra.com> *
"Service providers bullish on Inkra Networks' new data center architecture", INKRA NETWORKS (PRESS RELEASE), 19 February 2002 (2002-02-19), pages 1 - 2, XP002970846, Retrieved from the Internet <URL:www.inkra.com> *
See also references of EP1499991A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100488153C (en) * 2006-04-06 2009-05-13 中国科学院计算技术研究所 Virtual network service deriving and using method and device
CN107528714A (en) * 2016-06-22 2017-12-29 中兴通讯股份有限公司 script processing method, device, system and router

Also Published As

Publication number Publication date
EP1499991A1 (en) 2005-01-26
JP2005523621A (en) 2005-08-04
CN100568216C (en) 2009-12-09
US20030200295A1 (en) 2003-10-23
US7197553B2 (en) 2007-03-27
CN1659539A (en) 2005-08-24
AU2003225847A1 (en) 2003-11-03
EP1499991A4 (en) 2007-12-12
CA2483209A1 (en) 2003-10-30

Similar Documents

Publication Publication Date Title
US7197553B2 (en) Network system having a virtual-service-module
US7246178B2 (en) Methods and systems for changing a topology of a network
US11539753B2 (en) Network-accessible service for executing virtual machines using client-provided virtual machine images
US6393474B1 (en) Dynamic policy management apparatus and method using active network devices
EP1303096B1 (en) Virtual network with adaptive dispatcher
Fiuczynski et al. An Extensible Protocol Architecture for Application-Specific Networking.
CN112416737B (en) Container testing method, device, equipment and storage medium
CN112166579B (en) Multi-server architecture cluster providing virtualized network functionality
CN1988528A (en) Dynamic services blade and method
CN105407140A (en) Calculation resource virtualization system of networked test system and method thereof
Nakao et al. CoreLab: An emerging network testbed employing hosted virtual machine monitor
US8027817B2 (en) Simulation management within a grid infrastructure
US8447880B2 (en) Network stack instance architecture with selection of transport layers
CN115686729A (en) Container cluster network system, data processing method, device and computer program product
RU2298880C2 (en) Driver structure for network filters and operative control means for same
US20240089352A1 (en) Udp message distribution method, udp message distribution apparatus, electronic device and computer readable storage medium
CN116450351A (en) Edge container scheduling algorithm
CN115913778A (en) Network strategy updating method, system and storage medium based on sidecar mode
US20060253861A1 (en) API interface to make dispatch tables to match API routines
US20230138867A1 (en) Methods for application deployment across multiple computing domains and devices thereof
Fernando et al. Dynamic network service installation in an active network
Monaco Enabling Seamless Autoscaling of Service Function Chains in Kubernetes
Toggenburger Modular Network Router for Microkernel-Based Embedded Systems
Fernando A dynamically updatable active networking architecture
CN116016679A (en) Cloud primary service communication method, device, equipment and storage medium

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2483209

Country of ref document: CA

Ref document number: 2003586783

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2003746923

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 20038137534

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2003746923

Country of ref document: EP