Recent research in the area of active networking has demonstrated strong potential for this new technology. From the service point of view, active networking allows customized packet processing inside the network on a per-packet, per-flow, or per-service basis. Customized packet processing can be applied, for example, to application-aware routing, information caching, multiparty communications, and packet filtering [11]. From the management perspective, active networking technology facilitates rapid service deployment and flexible service management [5].
The paradigm of active networking allows a party to install and run a service on a network in a manner similar to the way a program is installed and executed on a computer. In this analogy, the network plays the role of the computer, which is simultaneously shared among many parties (that is, customers) and which is owned and operated by the network provider.
While suggesting attractive benefits, active networking also poses serious challenges that must be overcome for this technology to gain acceptance for use in telecom environments. A key challenge in this context is to develop a new concept for service creation and management. This concept must, on the one hand, enable customers to exploit customized packet processing, which translates into the ability to run their own services on the network. On the other hand, it must support providers in their effort to isolate different customers from one another in an efficient and effective way.
The tasks of service creation and management in active networks are different from those based on other networking technologies. In today’s Internet, service creation does not involve installing code inside the network, but only at terminals and servers at its edge. (Only recently has work begun to study programmable control planes for the Internet, which would provide such a capability.) Traditional telecom architectures generally allow for programmable information processing inside the network and support the engineering of new classes of services. In the case of the telephone network, the Intelligent Network (IN) architecture includes a service creation framework, in which services can be created from independent building blocks, and the service logic is subsequently spread out onto components that are uploaded into network control nodes [9]. For broadband and multimedia networks, the TINA architecture provides a similar framework [10]. In contrast to active networks, however, these approaches do not consider loading and executing customer-provided functionality in the network.
The problem therefore is essentially one of (a) developing a framework for customer-provider interaction in an active telecom environment, which allows a customer to install and run a service inside the provider’s network and (b) to create a concept for the customer to manage this service at runtime. (Note that the term “customer” can have different meanings here: it can refer to a business unit representing a multitude of employees, a user community, or a value-added service provider.)
Enabling a customer to install and run services in a provider’s domain requires an agreement between the two parties, the essential part of which is a framework of interactions between their respective control and management systems. This article presents such a framework, based upon the concept of network virtualization and on a generic service, which we call the Virtual Active Network (VAN) service.
The VAN captures the functionality and resources a provider offers to a customer. In the same way that an active network can be understood as a generalization of a traditional network, a VAN can be seen as a generalization of a traditional Virtual Private Network (VPN). Similar to a traditional VPN, a VAN can be used by a customer to run network services, using a provider’s physical infrastructure. In contrast to a traditional VPN, however, a VAN gives a customer a much higher degree of flexibility and controllability. We will show that the VAN not only is a very “natural” service abstraction for customers, but it also allows customers to create service management functionality and manage their services at runtime without interaction with the provider’s management system—a capability that is very difficult and costly to achieve in today’s telecom environments.
Furthermore, the VAN concept supports the capability to isolate customers from one another in order to avoid interference among its services. Our framework calls for mechanisms inside the provider’s active network nodes, in order to partition resources and monitor their consumption along VAN boundaries.
The Active Network Concept
The processing of packets (or cells) inside traditional networks is limited to operations on the packet headers, primarily for routing purposes. Active networks break with this tradition by letting the network perform customized computation on entire packets, including their payloads.
Active networks transport active packets [2] (also called capsules [11]). Active packets carry programs, in addition to data. A network node executes such a program, which possibly modifies the node’s state and possibly generates further active packets to be sent over the outgoing links. Specifically, an active packet can include a program that modifies or replaces the node’s packet-processing function.
Similar to traditional networks, an active network consists of active network nodes, which are connected via links. In addition to transmission bandwidth, the key resources of an active network node include memory and CPU resources for processing active packets.
We believe that, for the active networking approach to have significant impact on the development of the telecom field, two major obstacles related to performance and security must be overcome. First, it must be possible to build active networking nodes that process packets at a rate comparable to today’s IP routers or ATM switches. Second, it is crucial to engineer a secure environment in which different parties can share communication, processing, and storage resources.
The networking community is currently putting substantial efforts into investigating the active networking approach. The areas of current research are: designing execution environments for active network nodes [1, 12]; extracting application-specific functionality to be integrated into the network layer, such as application-specific caching [8], application-specific packet routing [3], media scaling [7]; and building high-performance active networking architectures [6].
A Management Framework for Active Telecom Networks
Here, we outline our management and interaction framework for active networks, which we first proposed in [5]. Figure 1 shows the interaction between a customer domain and a provider domain for service provisioning, service delivery, and service management. We propose that the provisioning of a specific (active) network service X is split into two different operations:
- The provisioning of a generic service, which we call the VAN service, is performed via the cooperative VAN provisioning interface, in cooperation with the provider. VAN provisioning includes the negotiation of the VAN topology and the VAN resources.
- The installation of the specific service X is performed via the generic service interface, without further interaction with the provider. The same interface is used to control and manage service X during its lifetime.
Three interfaces are introduced in Figure 1—the generic service interface, the cooperative VAN management interface, and the active network management interface. Using active networking nodes enables the definition of a generic service interface for network services based on the concept of active packets. In addition, this interface can be used for service management interactions, that is, for operations related to the installation, supervision, upgrading, and removal of a specific customer service. This way service management operations can be performed by a customer without interaction with the provider’s management system.
The management interface between network management systems of different domains is called the cooperative VAN provisioning interface. Similar to the service interface, this interface can be kept generic; it relates to a generic service abstraction (VAN), which allows for installing and running customer network services.
The active network management interface relates to the tasks of single-domain VAN configuration and network element management. As before, the active network management interface can be kept generic through the use of active packets (thereby replacing the standardized management protocols that implement the interaction between the network management system and the network to be managed). A generic management interface allows each administrative domain to implement its own management protocol if desired.
The Virtual Active Network
A Virtual Active Network (VAN) can be described as a graph of virtual active nodes interconnected by Virtual Links. Virtual active nodes are also called Execution Environments (EEs), following the terminology of the AN working group [2]. A virtual active node has resources attached to it in the form of processing and memory resources, provided by the underlying active networking platform. Similarly, a Virtual Link has bandwidth allocated to it. We envision that a single (physical) active node can run several virtual active nodes belonging to different VANs, and a single (physical) network link can support several Virtual Links for different VANs.
Figure 2 shows an active network with five nodes in a provider domain. On this network, two VANs have been installed, one for customer 1 and one for customer 2. The figure also shows the Management VAN, interconnecting the Management EEs, which are used by the provider for VAN provisioning and supervision (see the following section, “An Active Network Node Architecture”).
The VAN provides a generic service abstraction for an active network environment. From a provider’s point of view, the VAN is the entity according to which active network resources are partitioned and according to which customers, using the provider’s infrastructure, must be isolated from one another. The VAN is the only entity shared between provider and customer, and it is the object of negotiation between the two parties. Specifically, the provider is not concerned about which specific service(s) a customer is running on its VAN. The task of the provider is solely to configure a VAN and to monitor the use of resources at the VAN level. The provider has to ensure that the quality, as agreed upon between customer and provider, can be guaranteed. But the provider is not responsible for supporting any kind of customer service management.
In traditional network environments, the customer has a simple service abstraction and perceives a service essentially as a black box with access points. In contrast, the VAN is a much more flexible service abstraction than today’s virtual path or flow-based abstractions. For instance, customers can choose their VAN topology, which allows them to configure service abstractions with different degrees of complexity. A VAN can include EEs from every node in the provider’s domain, which results in a detailed service abstraction, giving a customer extensive control capabilities of the service on this VAN. At the other extreme, a VAN can be configured in a simple way, for example, providing only a Virtual Link through the provider’s network, comparable to the ATM Virtual Path abstraction, which leaves a customer with little capability for service control inside the provider’s domain. Generally, the level of detail a customer will choose will depend on the specific control and management objectives for the customer service on this VAN.
VAN provisioning allows for fine-grained resource allocation, which enables a customer to optimize the overall resource consumption of a service. Since the VAN can be seen as a collection of computation, communication, and memory resources located on active nodes and links, a customer can fine-tune the usage of each of these resources on every node. For instance, some services are computationally inexpensive but need a lot of memory, others require a lot of computing resources (before packets can be sent out on unreliable links, for example). In addition, the customer service manager can trade one resource for another, for example, in an effort to minimize the cost while maximizing the service quality.
From a customer’s perspective, the VAN concept allows for installation and management of active network services, without interaction with the provider. (As mentioned previously, all interactions between customer and provider relate strictly to the VAN.) The customer can run a variety of active network services on the VAN. These services are only restricted by the specific EEs the VAN supports. Furthermore, a customer can install service-specific customized service management functionality together with the service. Note that the flexibility of choosing a service abstraction and the degree of customer control over services running in a provider’s domain, which a VAN provides, is virtually impossible to realize with traditional networking technology.
Exploiting a general benefit of active networking, the VAN concept enables rapid deployment of new network services. Deploying and upgrading network services is difficult and time consuming in today’s networks due to the closed, integrated architecture of network nodes. With the concept of a VAN the installation of any customer-specific service becomes feasible. It can be accomplished by the customer alone, without interaction with the VAN provider, which speeds up service deployment considerably. This aspect is extremely useful in today’s marketplace, where the time to market is essential for profitable business.
Customers have the option to simultaneously run a variety of network services on a single VAN, which enables them to perform dynamic reallocation of VAN resources to the various services, according to their own control objectives and traffic characteristics—again, without interaction with the VAN provider.
We further illustrate the VAN concept by comparing it to a Virtual Path (VP)-based Virtual Private Network (VPN). Similar to a VAN, a VP-based VPN provides customers with a service abstraction, on which they can run their own services, such as IP-based data or real-time services. Since a VP is a simple abstraction, a customer’s ability to control traffic inside the provider’s domain is very limited. A VAN, on the other hand, is a more complex abstraction than a VP and, consequently, gives customers additional control capabilities inside the provider’s domain. In the case of a VP, a provider allocates bandwidth to it and offers QOS guarantees in terms of delay and error bounds for traffic traversing this VP. For a VAN, the resources to be allocated include processing cycles and memory on the VAN nodes, in addition to bandwith on the network links. The fact that the provider commits these resources to a VAN enables customers to achieve QOS objectives for the service(s) running on this particular VAN. In a similar way as dynamic bandwidth provisioning can be performed in a VP-based VPN, we envision that VAN resources can be renegotiated during the lifetime of a particular VAN via the cooperative VAN provisioning interface shown in Figure 1.
An Active Network Node Architecture
This section outlines our design of an active network node. It is similar to that of the AN Working Group [2], but specifically includes mechanisms for VAN support. Figure 3 gives an operating system point of view of an active network node. A node operating system layer configures and provides access to the node’s resources, such as links, processing and memory resources. This layer runs the EEs, separates them from each other, and polices the use of the resources consumed by each EE.
Figure 3 specifically shows the case where a provider offers VANs to several customers (Customer 1,…, Customer N). The figure captures one such node containing EEs of different customers/VANs. Each customer runs its services in a separate EE. The service components and service management components access the EE via the Service Programming Interface (SPI). The SPI includes functionality for processing active packets and for configuring EEs according to service-specific needs for functional and the runtime behavior. A special EE, called the Management EE, runs the provider’s VAN management and node configuration system. The Management EE accesses the Node Operating System via the Local VAN management interface. VAN provisioning and configuration is controlled by the provider’s management system via the exchange of active packets. The provider’s management system, as shown in Figure 1, maintains a global view of the provider’s domain for the purpose of VAN provisioning.
The Local VAN management interface (LVMI) provides methods for setting up Execution Environments, configuring Virtual Links, creating cut-through links, and monitoring the resource consumption of the EEs and Virtual Links. Table 1 lists functions in the local VAN management interface. The functions have Java-like notation with input parameters in brackets and return values written in front. A detailed description of the syntax and semantics of the local VAN management interface can be found in [4].
The functional requirements for the Node OS to support the VAN concept can be summarized in the following four points:
- Resource partitioning: resources, such as CPU cycles, memory, and transmission bandwidth of the outgoing physical links have to be partitioned among different EEs, that is, customers.
- Resource policing and isolation: an EE must be prevented from consuming more resources than granted by the VAN provider. Further, its allocated memory has to be protected from unauthorized read and write activity.
- Demultiplexing and multiplexing: active packets on an incoming physical link must be demultiplexed, identified, and forwarded to their corresponding EEs. Furthermore, active packets leaving the EEs need to be multiplexed onto the outgoing physical links.
- Cut-through links: the node operating system needs to support cut-through links, allowing packets to pass through the node on a fast path, without being processed.
Customer Service Provisioning and Management
Once a VAN is set up for a customer, the customer can configure the EEs (virtual nodes of the VAN) for the specific services it wants to run and for the service management functionality it needs. These operations are under full control of the customer and do not require interaction with the provider’s management system.
The task of customer service provisioning and management includes installation, supervision, update, and removal of active services on a particular VAN. As mentioned previously, this task can be compared to the customer installing and running a computer program on the provider’s computer. In this analogy, the computer is the provider’s active network and the program’s runtime environment is the VAN.
Figure 4 shows an example of a VAN that spans two provider networks and two local networks of a particular customer. Customer service provisioning and management are controlled from a service management station, which is attached to the VAN. This station provides a human-computer interface to the service management system for performing control operations and displaying VAN and service-related monitoring data.
We have realized the VAN concept and implemented a VAN provisioning and management architecture on ANET, an active networking platform developed in our laboratory at the TIK, ETH-Zurich [4]. The ANET platform is a Java-based, all-software, functional prototype of an active network, which allows us to evaluate and demonstrate active networking concepts.
On the ANET platform, we can demonstrate the installation, upgrading, and supervision of active services by a customer; we illustrate this with an IP service. (We have chosen IP because a well-known service makes a better example than a complex active service.) Installing an IP service on a active network node is achieved by configuring a virtual router inside the node’s EE. The customer service management system sends a sequence of active packets to the EE. Processing these packets results in installing an IP routing table, creating output buffers for the virtual out-bound links, setting up packet schedulers that operate on these buffers, installing function code for routing and management operations, configuring service-specific control parameters and management parameters, and so forth. After that, the IP service is initialized, which includes starting the routing protocol.
Upgrading the IP service to an IP service supporting several traffic classes with different QOS requirements is accomplished on ANET by reconfiguring the virtual routers inside the EEs. The customer service management system sends an active packet to each EE of the VAN. The processing of this packet results in upgrading the packet classifier (to detect the class of a packet), setting up buffers for each traffic class, and substituting the packet scheduler with a scheduler for multi-class traffic.
In our implementation, the customer service management system can change the partitioning of the output buffers by sending active packets to the virtual routers installed on the ANET platform. Further, it can monitor the buffer usage, by configuring the active management component to send packets back to the service management station in regular time intervals. This way, we can perform service management operations the same way as a customer would do while managing its IP service on a Customer Premises Network.
Conclusion
Since active networks enable customers to install and run their own customized services on a provider’s network, a framework for service creation and management for active networks in telecom environments is needed. We have presented such a framework in this article. A key problem in this context is how a customer, who wants to run a particular service on the network, and the provider, who owns the network, interact for the purpose of service installation and management. We have addressed this problem by introducing a generic service and by virtualizing the network.
To continue this work, a formal definition of the cooperative VAN provisioning interface, including the specification of VAN topology and the VAN resources, will be needed. This will allow us to automate customer-provider interactions for the purpose of VAN set up and maintenance. In addition, algorithms and mechanisms must be developed that map VAN specifications onto underlying network topologies. In the case of dynamic environments, such as VANs that support mobile services, it may become necessary to adapt the VAN topologies over time, for which mechanisms must be devised.
Network virtualization does have its costs. Realizing the VAN concept includes building a system for the network operator to create and maintain such VANs. Further, mechanisms must be introduced on the provider’s active network nodes to partition resources and monitor their consumption. It is of critical importance that these mechanisms are efficient. We believe that, in order to achieve efficiency, a set of VAN primitives must be supported by the node OS. We are currently pursuing this line of research as part of the FAIN project in the Fifth EC Framework Program, which began in June 2000. Our goal is to prove that high-performance active network nodes that support the VAN concept can be built.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment