Advanced Wireless Networks - 4G Technologies

16

Active Networks

16.1 INTRODUCTION

The basic goals of active networking (AN) are to create networking technologies that, in contrast to current networks, are easy to evolve and which allow application specific customization. To achieve these goals, AN uses a simple idea, that the network would be easier to change and customize if it were programmable [1–6]. While AN has the high-level goals of improving evolvability and customizabilty, there are a number of low-level concerns that must be balanced to achieve these goals. The first of these concerns is flexibility. AN systems aim to significantly improve the flexibility with which we can build networks. The second concern is safety and security. It is crucial that, while adding flexibility, we do not compromise the safety or security of the resulting system. The third concern is performance. If adding flexibility results in a system that cannot achieve its performance goals, it will be pointless. The final concern is usability. It is important that the resulting system not be so complex as to be unusable.

One of the basic techniques of AN is that code (program) is moved to the node at which it should execute. One place this idea first arose was in distributed systems supporting process migration. Another significant early influence was in generalization of remote procedure call (RPC) to support remote evaluation (RE). Both of these techniques will be discussed in detail in applications for network management in Chapter 18. The next important step in this direction was a DARPA proposal on the topic of ‘Protocol boosters for distributed computing systems’. The idea was to dynamically construct protocols using protocol element insertion and deletion on an as-needed basis, to respond to network dynamics. Protocols were constructed optimistically; that is, ideal operating conditions (no errors, low delays, adequate throughput, etc.) were assumed, and protocol elements (such as error detection and correction mechanisms) were inserted into protocols on-demand, as conditions were encountered that deviated from the best case where the protocol element would not be needed.

Advanced Wireless Networks: 4G Technologies Savo G. Glisic

C 2006 John Wiley & Sons, Ltd.

630 ACTIVE NETWORKS

On the network level the previous concepts resulted in middleboxes [7]. Domain-specific ‘middleboxes’ [7] are appearing such as firewalls, network address translators (NATs) and intrusion detection systems (IDSs). Examples of such middleboxes include NATs [8–10], NAT with protocol translator (NAT-PT) [11], SOCKS gateway [12], Packet classifiers, markers and schedulers [13], TCP performance enhancing proxies [14], IP firewalls [15, 16], gatekeepers/session control boxes [17, 18], transcoders, proxies [17, 19]. These various application-driven ad hoc examples of STF (store, translate and forward) functionality can be unified in a common framework, and embedded in a common programming model reinforced with the safety and security.

The IETF’s forwarding and control element separation (ForCES) working group [20] models router architectures in a way that allows the introduction of programmable and active technologies into the Internet control plane, in the style of base building block (BBN)s FIRE [21].

The principal observation here is that forwarding and routing are distinct activities. Routing is part of the ‘control plane’ of the IP Internet, while forwarding is the ‘transport plane’. These activities were consolidated in traditional IP routers, but are now recognized as logically separate (viz. MPLS). The separation permits more general network elements to replace IP routers in performing control plane activities, allowing distributed routing with improved performance, slightly more global optimization, and perhaps surprisingly, an increase in security. In addition, the separation of routing and forwarding functions permits decoupling of their performance, allowing better tracking of technology improvements in both forwarder mechanics and routing algorithms.

Active router control uses fast forwarders as a virtual link layer, managed by specialized active router controllers (ARCs), as shown in Figure 16.1. Using a set of routers as a ‘router in a room’ is not uncommon; one could simply reduce their autonomy and specialize them to IP forwarding, making way for source routing over all optical networks or routing/router control internal to the network. The use of general purpose network elements permits this separation of concerns, while offering the potential for improvement of the Internet on a number of axes.

Figure 16.1 Active router controller managing a set of forwarder/routers.

NodeOS

Router

Figure 16.5 Active node architecture.

The NodeOS simultaneously supports multiple EEs. Its major functionality is to provide isolation among EEs through resource allocation and control mechanisms, and to provide security mechanisms to protect EEs from each other. It may also provide other basic facilities like caching or code distribution that EEs may use to build higher abstractions to be presented to their AAs. All these capabilities are encapsulated by the node interface through which EEs interact with the NodeOS. This is the minimal fixed point at which interoperability is achieved [31]. In contrast EEs implement a very broad definition of a network API ranging from programming languages to virtual machines, to static APIs in the form of a simple list of fixed-size parameters, etc. [32]. EE takes the form of a middleware toolkit for creating, composing and deploying services.

The AN reference architecture [30] is designed for simultaneously supporting a multiplicity of EEs at a node. Only EEs of the same type are allowed to communicate with each other, whereas EEs of different type are kept isolated from each other. A thorough analysis and comparison of programmable networks may be found in References [33, 34].

The FAIN (future active IP network) NE reference architecture is depicted in Figure 16.6. It describes how the ingredients identified previously may synergistically be combined in building next-generation NEs capable of seamlessly incorporating new functionality or dynamically configured to change their behavior according to new service requirements. One of the key concepts defined by the FAIN architecture is the EE. In FAIN, drawing from an analogy based on the concepts of class and object in object-oriented systems, we distinguish EEs between the EE type and the EE instances thereof.

An EE type is characterized by the programming methodology and the programming environment that is created as a result of the methodology used. The EE type is free of any implementation details. In contrast, an EE instance represents the realization of the EE type in the form of a runtime environment by using specific implementation technology, e.g. programming language and binding mechanisms to maintain operation of the runtime environment. For details see References [21, 35].

Figure 16.6 FAIN NE reference architecture.

16.3 EVOLUTION TO 4G WIRELESS NETWORKS

Given the volume of investments in existing networks infrastructure, a possible way to 4G might be evolution rather than any revolution. By ‘network evolution’ we mean any incremental change to a network that modifies or enhances existing functionality or adds new functionality. In the context of active networking, evolution should be able to occur at remote nodes while the network is operational with only minimal disruption to existing services. AN achieves evolution by changing the programs that operate the network. Thus the ways in which we can evolve the network are dictated by the programmability mechanisms that are available to make such changes.

Active packets (AP) are perhaps the most radical AN technology for evolution and they are the only mechanism that, at a high-level, are specific to AN. Such packets carry (or literally are) programs that execute as they pass through the nodes of network. A packet can perform management actions on the nodes, effect its own routing, or form the basis of larger protocols between distributed nodes, e.g. routing protocols. Such packets (ANTS [38], Smart Packets [39] and PLAN [40]) are like conventional packets, but with qualitatively more power and flexibility.

Active packet evolution does not require changes to the nodes of the network. Instead, it functions solely by the execution of APs utilizing standard services. The disadvantage of

636 ACTIVE NETWORKS

this approach is that taking advantage of new functionality requires the use of new packet programs. This means that at some level the applications using the functionality must be aware that the new functionality exists. This is the kind of evolution facilitated by pure AP systems, such as ANTS [38] and in essence it embodies the AN goal of application-level customization.

The programmability mechanism that is broadly familiar outside the AN community is the plug-in extension. Plug-in extensions can be downloaded and dynamically linked into a node to add new node-level functionality. For this new functionality to be used, it must be callable from some prebuilt and known interface. For example, a packet program will have a standard way of calling node resident services. If it is possible to add a plug-in extension to the set of callable services (typically by extending the service name space) then such an extension ‘plugs in’ to the service call interface.

The programmability mechanism known as the update extensions may also be downloaded, but they go beyond plug-in extensions in that they can update or modify existing code and can do so even while the node remains operational. Thus, such extension can add to or modify a system’s functionality even when there does not exist an interface for it to hook into.

An example of AP evolution program written in a special-purpose language, PLAN (packet language for AN) [40], for mobility management protocol can be found in Song et al. [36]. Before a mobile node leaves its home network, it must identify the router that serves as its home agent. For simplicity, it is assumed that its default router serves this purpose. Once the node has attached itself to a new network and has a unique address, it sends an AP containing a control program to register itself to its home agent. When executed, this program simply adds the information to the home agent’s soft-state keyed by the mobile node’s home network address. Both the application aware and transparent versions share the same soft-state entries, allowing them to use the same control program and to co-exist.

Figure 16.7 illustrates how we detect that a packet is at the home agent of a mobile host and how the packet is then tunneled to the unique address. The PLAN code for the packet

app aware

active packet

Subnet 3

CH

HA

(unchanged)

Subnet 1

MH

MH

Subnet 2

Figure 16.7 Active packets for mobile-IP (MH, mobile host; HA, home agent; CH, corresponding host.)