This paper presents the design and implementation of the Intentional Naming System (INS), a resource discovery and service location system for dynamic and mobile networks of devices and computers. Such environments require a naming system that is (i) expressive, to describe and make requests based on specific properties of services, (ii) responsive, to track changes due to mobility and performance, (iii) robust, to handle failures, and (iv) easily configurable. INS uses a simple language based on attributes and values for its names. Applications use the language to describe what they are looking for (i.e., their intent), not where to find things (i.e., not hostnames). INS implements a late binding mechanism that integrates name resolution and message routing, enabling clients to continue communicating with end-nodes even if the name-to-address mappings change while a session is in progress. INS resolvers self-configure to form an application-level overlay network, which they use to discover new services, perform late binding, and maintain weak consistency of names using soft-state name exchanges and updates. We analyze the performance of the INS algorithms and protocols, present measurements of a Java-based implementation, and describe three applications we have implemented that demonstrate the feasibility and utility of INS.

Attempts to generalize the Internet's point-to-point communication abstraction to provide services like multicast, anycast, and mobility have faced challenging technical problems and deployment barriers. To ease the deployment of such services, this paper proposes an overlay-based Internet Indirection Infrastructure (i3) that offers a rendezvous-based communication abstraction. Instead of explicitly sending a packet to a destination, each packet is associated with an identifier; this identifier is then used by the receiver to obtain delivery of the packet. This level of indirection decouples the act of sending from the act of receiving, and allows i3 to efficiently support a wide variety of fundamental communication services. To demonstrate the feasibility of this approach, we have designed and built a prototype based on the Chord lookup protocol.

The Internet protocols were designed to emphasize simple routing elements and intelligent hosts. However, there are applications that benefit from allowing hosts to customize or program routers, a concept known as active networking. Since routers are shared, this raises challenges with delivering sufficient flexibility while preserving or improving performance, security, and safety. PLAN (Packet Language for Active Networks) is a language designed for the SwitchWare active network architecture. This architecture comprises active packets containing PLAN programs that invoke service routines over an active OS. PLAN is based on the polymorphic lambda calculus and provides a restricted set of primitives and datatypes that enables reasoning about its impact on network resources based on features of the language design. This paper focuses on the PLAN language with the aim of consolidating a variety of studies that were carried out in the years after its introduction in 1998. These studies include the requirements for PLAN, its design, programming in PLAN, the specification and theory of PLAN, and its use in networking applications.

The state of the art of the field of feature interactions in telecommunications services is reviewed, concentrating on three major research trends: software engineering approaches, formal methods, and on line techniques. Then, the impact of the new, emerging architectures on the feature interaction problem is considered. A forecast is made about how research in feature interactions needs to readjust to address the new challenges posed by the emerging architectures.

We present SNAP (Safe and Nimble Active Packets), a new scheme for programmable (or active) packets centered around a new lowlevel packet language. Unlike previous active packet approaches, SNAP is practical: namely, adding significant flexibility over IP without compromising safety and security or efficiency. In this paper we show how to compile from the well-known active packet language PLAN [7] to SNAP, showing that SNAP retains PLAN's flexibility; give proof sketches of its novel approach to resource control; and present experimental data showing SNAP attains performance very close to that of a software IP router. Keywords---Active networks, active packets, capsules, resource control. I.

Abstract: The current Internet is at an impasse because new architectures cannot be deployed, or even adequately evaluated. This paper urges the community to confront this impasse, and suggests a way virtualization might be used to overcome it. In the process, we discuss the nature of architecture and the debate between purists and pluralists. 1.

We recognize two trends in router design: increasing pressure to extend the set of services provided by the router and increasing diversity in the hardware components used to construct the router. The consequence of these two trends is that it is becoming increasingly difficult to map the services onto the underlying hardware. Our response to this situation is to define a virtual router architecture, called VERA, that hides the hardware details from the forwarding functions. This paper presents the details of VERA and reports our preliminary experiences implementing various aspects of the architecture.

Active Networks promise greater #exibility than current networks, but threaten safety and securityby virtue of their programmability.

Today, an increasing number of important network services, such as content distribution, replicated services, and storage systems, are deploying overlays across multiple Internet sites to deliver better performance, reliability and adaptability. Currently however, such network services must individually reimplement substantially similar functionality. For example, applications must configure the overlay to meet their specific demands for scale, service quality and reliability. Further, they must dynamically map data and functions onto network resources---including servers, storage, and network paths---to adapt to changes in load or network conditions.

ABSTRACT Recent efforts to add new services to the Internet have increased the interest in software-based routers that are easy to extend and evolve. This paper describes our experiences implementing a software-based router, with a particular focus on the main difficulty we encountered: how to schedule the router's CPU cycles. The scheduling decision is complicated by the desire to differentiate the level of service for different packet flows, which leads to two fundamental conflicts: (1) assigning processor shares in a way that keeps the processes along the forwarding path in balance while meeting QoS promises, and (2) adjusting the level of batching in a way that minimizes overhead while meeting QoS promises. 1.