Implementation of End-to-End Abstractions in a Network
Service Architecture
Shashank Shanbhag and Tilman Wolf
Department of Electrical and Computer Engineering
University of Massachusetts, Amherst, MA, USA
{sshanbha,wolf}@ecs.umass.edu
ABSTRACT
(e.g., peer-to-peer) need to be implemented as inefficient end-system overlay networks, etc.
To address these problems, the networking research
community is in the process of exploring new network
architectures that can provide the foundations of the
next-generation Internet. These new architecture do
not need to be backward compatible with the current
Internet and thus can be considered clean-slate [11]. In
this context, we propose a novel network architecture
that centers on the concept of a network service. A network service is any type of processing function that is
performed in the data path of the network. By combining sequences of predefined network services, endsystems can establish connections with custom communication characteristics. New services can be deployed in the network as new networking concepts are
invented. An efficient implementation of network services can be achieved with programmable routers [29],
which are equipped with high-performance packet processing systems.
A major challenge with network services (or any other
approach to providing advanced functionality in the
network data path) is the need for abstractions that
allow end-system applications to make use of such features. Similar to how BSD sockets [9] allow easy access to the TCP/IP protocol stack in the existing Internet, it is essential to develop simple end-to-end abstractions for network architectures where more complex features are available in the data path. In this
paper, we present a service socket abstraction that can
be used by end-system applications to specify data path
services in connection requests. These requests are then
used by the network to setup and control data path services accordingly. We demonstrate the functionality of
this approach with an evaluation of our prototype implementation. The specific contributions of this paper
are:
To support the increasing diversity of systems and protocols
in the Internet, modern routers offer a variety of data path
processing functions. Such “network services" are easy to
implement on a single node, but a network-wide deployment
is difficult. We discuss our implementation of a network service architecture that uses novel end-to-end abstractions to
access and control advanced data path functions. To make
such functions available to end-system applications, we introduce a “service socket" API. We demonstrate the operation of this network architecture and its socket API in the
context of a video distribution scenario that we have implemented on a 60-node Emulab testbed.
Keywords
next-generation Internet; network architecture; data
path service; network socket
1. INTRODUCTION
Modern computer networks have to adapt to an increasing diversity of connected end-systems, novel protocols, and innovative data communication paradigms.
The existing Internet architecture has been very successful in providing end-to-end connectivity using highspeed routers that provide a bare minimum of functionality to move packets from one node to another [8].
However, this architecture shows shortcomings in the
context of emerging technologies: sensor networks cannot communicate using standard Internet abstractions
due to their inherent processing and power limitations,
security protocols (e.g., to protect from DoS attacks)
are difficult to deploy inside the network, new networking concepts that deviate from client-server paradigms
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
ACM CoNEXT 2008, December 10-12, 2008, Madrid, SPAIN
Copyright 2008 ACM 978-1-60558-210-8/08/0012 ...$5.00.
• We present an overview of the design of our network service architecture. Some aspects of this
overview have been introduced in prior work.
• We introduce service sockets as end-system interface to interact with the network service architec1
method of specifying services similar to pipeline abstractions [19]. Another general approach to managing network functionality is the SILO architecture [22],
which provides mechanisms for composing custom protocol stacks [2]. Our work is not limited to a layered
composition of function, but allows a more general sequential composition of services.
A number of previous research projects have addressed service composition in networks. The SpiderNet project [14] provides a decentralized approach to
service composition in P2P networks. Similarly, [20]
discuss the challenges involved in service composition
on top of the Internet Indirection Infrastructure (i3 )
and suggest a few approaches to address them. Their
work stresses on the importance of the decentralization
of service path selection and service composition. In
our network service architecture, the path selection is
also done in a distributed manner [17], but end-systems
and other entities along the path may specify specific
service requirements. The CANS architecture [12] uses
abstractions similar to our network service concept, but
does not present an actual implementation to support
the choice of abstractions. Schmitt et al. [24] present
a user-level abstraction (also called service sockets) to
implement various networking applications and services
in networks where services are implemented on endsystems. The application using the service sockets interface makes use of BSD sockets for connection setup
and data transfer. Our work on service sockets focuses
on the next-generation Internet architecture where services are implemented in the data path of routers.
In the context of next-generation Internet platforms,
virtualized routers have been proposed [1]. Such systems allow the existence of multiple parallel network
architectures. We envision that our network service architecture can be deployed as one such slice. Several experimental platforms are currently in use to transition
towards such an environment (e.g., PlanetLab [4] and
high-performance implementation [26], Emulab [28]).
ture. We present a service socket API and discuss
how it can be used to set up and control connections in a network service architecture.
• We present results from a prototype implementation of this network service architecture using service sockets. The prototype consists of 60 nodes on
Emulab and uses an IPTV transmission scenario
as an example application.
The remainder of this paper is organized as follows.
Section 2 discusses related work. Our network service
architecture is introduced in Section 3. Section 4 discusses how end-to-end connections can be established
using service sockets. A prototype implementation of
our system is discussed in Section 5 and example usage
scenarios are presented in Section 6. Section 7 summarizes and concludes this paper.
2. RELATED WORK
A number of different approaches have been proposed
to extend and adapt the functionality of the original Internet architecture. Point solutions to specific problems
have been implemented (e.g., network address translation to allow IP address reuse [10], firewalls to improve security [21]). Protocol extensions have been
proposed to provide data path flexibility (e.g., active
networks [25], configurable protocol stacks [6], protocol heaps [7]). Advanced router systems have been designed to extend the processing steps that can be performed on packets (extensible workstations routers [18],
programmable routers [23], and virtualized router platforms [1]). In our work, the basic concepts to describe
advanced networking functions are network services.
These were introduced in our earlier work [13, 30] and
are described briefly in Section 3.
One of the main challenges with providing new network capabilities is finding a way of allowing management and control. For example, active networks [25]
provided a powerful and very general approach to customizing packet processing. However, allowing anybody
to program network features was too general an approach. Active networks were difficult to control and
nearly impossible to use for application programmers.
To manage (and limit) the complexity of new features
in the network, an IETF working group has attempted
to define Open Pluggable Edge Services (OPES) [3].
In such an architecture, end-systems can specify a set
of data flow operations that are implemented on nodes
throughout the network. For connection establishment,
Guha and Francis address the problem of traversing
multiple “middle-boxes” in the current Internet [15].
While their work focuses specifically on traversing firewalls and network address translators, it can be seen
as a step towards managing connections involving general services. In our work, we provide a more general
3.
NETWORK
TURE
SERVICE
ARCHITEC-
The end-to-end abstractions that we present in this
paper are based on the network service architecture that
we describe in more detail in this section.
3.1
Network Services Concepts
The basic idea behind our network service architecture is to decompose the functions performed on a connection into basic components (called “network services”). Examples of such network services are reliable
data transfer (as in TCP), firewalls, intrusion detection, multicast, privacy and authentication. Note that
these services are implemented in the data path of the
network and act on all (or a subset of) packets. With
2
network into control and data plane. We use two types
of nodes to perform the main functions in each domain.
Service Controllers are used in the control plane to establish connections. When an end-system requests a
new connection, it sends the service specification to its
local Service Controller. Some of the requested services
may be performed locally and the remaining request is
forwarded to a downstream Service Controller. Once
the connection is established, the end-system is notified
and then can send traffic. Note that Service Controllers
and Service Nodes are clustered into Autonomous Systems to reflect the administrative structure of the current Internet. More details on the general concepts of
a network service architecture can be found in [30].
In the context of this architecture, we make several
general assumptions to make such a system practical:
Figure 1: Network with Data Path Services.
Connection requests specify sequence of services
that need to be allocated by network.
ServiceEnabled
Service
Controller
Control plane
EndSystem
Data plane
Network
Service
Node
• We can control the path of traffic at the network
layer (e.g., through circuit switching or tunneling)
to ensure connections traverse the intended service
nodes. To be able to provide a specific description
in this paper, we assume we use a network with
UDP tunnels over IP. In the future, this configuration can easily be changed as novel network
protocols emerge.
EndSystem
Service
Node
Service
Node
Service
Controller
Service
Node
Service
Node
Service
Node
Service
Node
Figure 2: Network Service Architecture. Service Controllers establish connections and set
up service nodes (control plane). Service Nodes
implement data path services (data plane).
Autonomous System boundaries shown with
dashed lines.
• We expect that the number of services is in the order of tens (i.e., not thousands). Services would be
approved by standardization bodies (e.g., IETF)
to ensure wide deployment.
• For the discussion in this paper, we do not consider
issues of fault recovery (e.g., broken link, malfunctioning service node), choice of service functionalities, commercial incentives, or hardware processing platforms to implement such services since
these topics are covered sufficiently by others in
related work.
networking functions decomposed into basic services,
connections can then compose a custom sequence of
such services to be applied to the packets transferred
in this connection. Such a custom composition allows
end-system applications to make the best use of functionality of the network.
An example of a network service connection is illustrated in Figure 1. At the bottom of the figure, a connection setup request with two services is shown. Such
a request is provided by the end-system to the network
at the time of connection setup. The network then determines which nodes are capable of performing the requested services (denoted by corresponding colors) and
chooses one for each service (arrows). The connection is
then established such that traffic traverses these nodes
on the way from one end-system to the other. During
the setup, service nodes are informed what kind of processing the packets of a particular connection require.
Once packets are sent via this connection, the correct
set of services is performed along the way.
One of the main questions about such a network service architecture is how to structure the network internally to permit an effective and efficient implementation. In Figure 2, we illustrate how we separate the
3.2
Router Architecture
To provide more details about the operation of our
network service architecture, we briefly discuss the operation of a network service router system. Such a system is illustrated in Figure 3, where the Service Controller functionality is shown in the upper half and the
Service Node functionality is shown in the lower half.
Both functions may be collocated on the same system
or may be set up in a distributed fashion.
The Service Controller interacts with end-systems
and other Service Controllers. Its main function is to
route service connection requests. This requires it to
determine:
• Which of the requested services are locally available and are most efficiently performed locally?
This question is difficult, because there may be
more capable service nodes downstream.
3
Service Controller
EndSystem
.
.
.
EndSystem
Connection Management
Connection Management
Connection Management
Interface to End-Systems
Interface to Service
Request Parser
Controllers
Controller View of
Local Network
and Resources
Application
Service
Controller
.
.
.
svc_send
svc_request
svc_recvfrom
Service
Controller
User Space
Service
Operating
Socket API
System
Service Sockets
Legacy
Connection
TCP/IP
Data Transfer
Setup
Sockets
Flow Manager
Distributed
Service Matrix
Routing
Algorithm
Flow
Configuration
Control Interface to Service Nodes
Control Interface to
Local Service
Controller
NIC Driver
I/O System
Service Node
Resource Monitor
Flow Manager
... Service
Node
Service
Node
Service Manager
Processing
Service
Flowindependent
Processing
State
Flow
Configuration
and State
Packet Demultiplexer
Legacy Application
Service
Controller
Figure 4: Applications Use Service Socket API
on End-System to Access Network Services.
Legacy applications can be supported through
a parallel network stack.
Packet Scheduler
I/O System
sure that the correct services (or no services) are applied. To manage state information correctly, both flowdependent and flow-independent state is managed in
the Service Node. A resource monitor informs the Service Controller of the local processing load and link utilization to ensure that resources are managed suitably
during connection setup. More details on the design
of Service Controllers and Service Nodes can be found
in [13].
Figure 3: Network Service Router System. Service Controller functionality is shown in the upper half, Service Node functionality is shown in
the lower half. Both functions can be co-located
on routers.
• On what route should traffic be sent to the destination? While the shortest path may be ideal to
minimize communication cost, it is not guaranteed
that the best service nodes are encountered along
the way.
3.3
End-System Architecture
The main focus of this paper is on the end-system and
the design of end-to-end abstractions that allow for easy
access and control of network services. In Section 4, we
discuss these abstractions in more detail. Here, we just
illustrate how end-systems fit into the network service
architecture that we have described above.
The main interface between applications and our network service architecture are service sockets. These
sockets are conceptually similar to conventional TCP
and UDP sockets, but provide a mechanism for exchanging a service specification. The service specification tells the network what services are required by the
application.
Figure 4 illustrates an end-system with support for
service sockets. The connection setup component is
used to communicate with Service Controllers during
connection establishment. For data transfers, traffic is
sent directly to service nodes. The service socket API,
To solve this problem, we have presented a Distributed
Service Matrix Routing (DSMR) algorithm in [16].
DSMR phrases the routing problem as a dynamic programming problem similar to how shortest path routing
can be expressed with the Bellman equation [5]. In a
distributed implementation, a “service matrix” is exchanged between (Service Controller) nodes (instead of
a distance vector). This matrix is used to determine
which services should be performed locally (i.e., within
the Autonomous System that is managed by the Service
Controller) and where to send the remaining request.
The services that are performed locally are set up
through a control interface between the Service Controller and each Service Node. On a Service Node, information about each traversing flow is stored to en4
• Network service: A network service takes network
traffic in on the receiving side and generates network traffic on the transmitting side. Often, there
is a one-to-one relationship between received and
transmitted packets (e.g., when performing network address translation), but such behavior is
not required. The network service is specified by
a unique and global name (e.g., could be assigned
by IANA) and thus there is no ambiguity about
what functionality this service implements.
which is explained in more detail in Section 4, uses commands similar to those of a conventional UDP socket.
Note that service sockets can exist in parallel to legacy
sockets.
4. END-TO-END ABSTRACTIONS
It is essential that network services can be easily accessed and controlled by end-system applications. Complexity in setting up simple communication scenarios
would present a major hurdle in technology acceptance.
Therefore, the goals for the design of end-to-end abstractions in our network service architecture are:
• Sink: The sink of the service pipeline is the receiving end-system. Its IP address and port number
must be specified. It is expected that an application is listening on that port to receive and process
the incoming data.
• Develop simple specification and composition
mechanism for network services,
• Use familiar functions for connection setup and
data operations, and
In any service pipeline, we need the source and
sink exactly once. Intermediate network services may
appear an arbitrary number of times (including zero
times). It is important to note that in a network service
pipeline – as in a Unix pipeline – all elements operate
at the same time in parallel. Operations by network
services are performed as packets traverse the network.
• Provide abstractions that can make full use of the
capabilities of service-enabled networks.
To achieve these goals, we take the following approach. We use service specifications to express the
functional requirements of a connection. This information is passed to the system during the connection
setup. Once a connection is established, we use conventional functions similar to those used in Berkeley sockets. The use of these well-understood abstractions ensures that application developers can use familiar concepts for packet I/O.
4.1.2
The syntax of our service specification is similar to
the Unix pipeline, but adapted to the networking environment:
• Source/sink: Source and sink are represented by a
sequence of IP address and port number separated
by a ‘:’ (e.g., 192.168.1.1:80). The source may
leave the IP address and/or port unspecified (e.g.,
*:*).
4.1 Service Specification
The main complexity of service sockets lies in the
service specification. Once the requirements for a connection have been specified, a service controller can
translate this specification into a corresponding connection. We first show how services can be expressed as a
pipeline. Then we discuss how such a specification can
be created when multiple parties are involved in the
process.
4.1.1
Service Specification Syntax
• Network service: The service is specified by its
name. If configuration parameters are necessary,
they are provided as a sequence in parentheses after the name (e.g., compression(LZ) specifies a
compression service that uses the Lempel-Ziv algorithm).
• Concatenation: The concatenation of source, network service(s), and sink is indicated by a ‘>>’
symbol.
Service Pipeline
A service pipeline is a concept derived from Unix
pipelines, where the ‘|’ symbol is used to chain the
output from one shell command to the input of another (e.g., cat * | grep "service" | wc -l counts
the number of lines in which the work “service” appears
among all files). In a service pipeline, the operations
are not performed on a file, but on the network traffic
transmitted between end-systems. Thus, we need three
distinct elements:
Thus, an example of a service specification for a transmission to 192.168.1.1:80 using packet compression
along the way is:
*:*>>compression(LZ)>>decompression(LZ)
>>192.168.1.1:80
Note that the service specification does not indicate
where the compression and decompression step should
occur. We believe this decision is best made by the
network. As Service Controllers process the connection
request, the DSMR algorithm can be used to find a
near-optimal allocation.
• Source: Similar to conventional sockets, the source
is specified by an IP address and port number.
Typically, both are chosen by the operating system
and thus can be left unspecified.
5
4.1.3
Composition Constraints
the control plane) may add a transcoding service
as needed.
When composing network services as a sequence
of operations, there are clearly constraints on what
service sequences lead to useful network connections.
For example, it is generally undesirable to perform
intrusion detection on packets with encrypted payloads. Thus, it would be preferable to decrypt the
packet before using the intrusion detection service. Another constraint is that some services are typically
used in pairs (e.g., encryption/decryption, compression/decompression). Thus we observe the following
constraints:
• Network service provider: The network service
provider may add services that are necessary due
to local policies and to ensure efficient operation
of its network. For example, a network service
provider may use a service to enforce bandwidth
limits for traffic from different customers.
Note that only the sender’s service specification is necessary. Receiver and network service provider may add
theirs optionally.
The composition process of a service specification
from multiple parties is illustrated in Figure 5. The
sender requests to connect to the receiver’s web server.
The receiver adds a proxy service (e.g., to reduce the
load on the web server generated by requests for static
web content). Again, the sender could not have added
this service since it is not familiar with the operational
issues of the receiver. The network service provider adds
a monitoring service in its network to track network usage. This example illustrates the elegance with which
multiple parties’ different needs for services can be accommodated.
A related issue is that of transparency when using
network services. In the current Internet, many middleboxes perform operation on network traffic [15]. Endsystems are typically unaware of such operations since
they assume that the network performs only store-andforward operations. With service specifications, this
problem can be solved by simply reporting the final service specification to all parties. Thus, all parties can be
fully aware of what operations are being performed on
their traffic.
• Service pairs: Some services need to be used in
pairs.
• Service semantics: Some services change the properties of the data stream. This may have an effect
on other services that use this data downstream.
One key question in the design of end-to-end abstractions for network services is if such constraints should
be enforced by the network system. Alternatively, the
network can ignore these constraints and rely on the
programmer to compose a valid sequence of services.
The first approach has been explored to a small extend [27], but no established solution is available. The
latter approach is more general since it allows for new
applications that could not have been predicted. For
example, by violating the service pair constraint, one
could develop a system that uses encrypted network
storage. Encryption (only) is used for transfers towards
the storage and decryption (only) is used for transfers
from storage.
While our prototype implementation below supports
context-free grammars (and thus is able to express pair
relationships), we pursue the latter approach of giving
responsibility to the end-system application to create a
valid service specification.
4.1.4
4.1.5
Advanced Specification Features
There are a number of features that can be added to
the service specifications that we describe above. Some
of these features are:
Multi-Party Service Composition
A very attractive feature of service specifications is
that they can easily be extended. This feature is particularly useful when the set of services involved in a
connection is not only determined by the sender, but
by multiple parties. Typically, there are three parties
who may contribute to a service specification:
• Optional services: Some services are optional and
are not necessary for correct operation. However,
they can opportunistically improve performance.
An example is a compression/decompression service pair to reduce bandwidth consumption (e.g.,
on satellite links).
• Sender: The sender initiates the connection and
provides an initial service specification for correct
operation of the application.
• Location constraints: Some services need to be
performed at a particular node or in a particular subnet to be effective. Examples are a reliable
transmission service, which should be installed on
the source (and sink) nodes, and a VPN service,
which should perform encryption within the local
trusted network and decryption within the remote
trusted network.
• Receiver: The receiver may add services to ensure
efficient and correct operation. For example, a receiver may require transmissions using a particular protocol or data format. A sender may not be
aware of this requirement, but the receiver’s Service Controller (after exchanging information in
6
Figure 5: Example of Multiparty Service Specification. Sender, receiver, and network service provider
contribute to complete service specification
• Services without order constraints: Some sets of
services can be performed in arbitrary order. An
example is a network address translation service
and an intrusion detection service, where either
order of service leads to correct operation.
send traffic to the first service node.
• int svc send(int svc socket, const void *
data, int length)
Parameters: The function takes a service socket,
a pointer to data that should be transmitted and
the length of the data as inputs. The return value
is the number of bytes sent or −1 in case of an
error.
Description: The svc send routine forms a packet
containing the provided data and sends it to the
first service node (or the destination in case no
service is set up).
While we are aware of such cases, we do not discuss
specific syntactical extensions for these scenarios in this
paper.
4.2 Service Sockets
The service socket API that we propose for our system uses functions that are conceptually similar to those
used in Berkeley sockets [9]. We use the datagram send
and receive operations since the baseline functionality
of the network service architecture is based on packets.
For stream sockets, a service can be used for conversion.
It is also possible to support stream sockets natively, but
we do not consider this approach further to simplify the
discussion.
The three function calls that the service socket API
supports are:
• int svc recvfrom(int svc socket, void *
data, int length)
Parameters: The function takes a service socket,
a pointer to memory to store the received packet
and its length as inputs. The return value is the
number of bytes received or −1 in case of an error.
Description: The svc recvfrom routine receives
packets from a service socket.
• int svc request(char * srv spec)
Parameters: The function takes a service specification (character string) as input and returns a
service socket. The return value is zero if an error
occurred (with the error indicated by errno).
Description: This function sets up a connection
with services requested in the service specification.
The service specification is parsed to determine the
source and destination IP addresses and port numbers. Then the specification is passed to the local
Service Controller for further routing and setup.
Once the path and services are set up, the control responds by providing the IP address and port
number of the next service to which packets need
to be sent. When using an implementation with
UDP tunneling, a UDP socket is established to
The simplicity of the service socket API can be attributed to the way service specifications capture network processing services in an easy to understand representation. This simplicity allows applications to make
use of relatively complex features in the network while
still using a simple and well-understood socket API.
5.
PROTOTYPE SYSTEM IMPLEMENTATION
We have implemented the system described above in
a prototype. In this section, we describe the implementation of end-to-end abstraction in general. Section 6
discusses particular application scenarios specifically.
5.1
7
Emulab Prototype
Figure 7: Implementation of Service Socket API.
troller. Thus, connectivity between neighboring
autonomous systems can be established in the control plane.
AS 9
• Service Controllers implement Distributed Service
Matrix Routing to determine which services are
available where. Using this routing algorithm,
connections are set up and services are allocated.
AS 8
AS 4
AS 7
AS 2
AS 5
AS 6
AS 3
• End-systems implement the service socket API as
a library (i.e., in user-space, not in the kernel, yet).
AS 11
• End-to-end connections as described above can be
established successfully and can be used for applications (see Section 6).
AS 12
AS 1
AS 10
The prototype topology used on Emulab is shown
in Figure 6. It consists of 60 nodes organized into 12
autonomous systems (each with one Service Controller
and four Service Nodes).
Figure 6: Topology of Prototype System in Emulab.
5.2
Service Sockets API
The service socket API is implemented with the functionality discussed in Section 4. For the prototype, the
API is implemented as a library that can be linked to
the application. In future implementations, we expect
to implement the library as a kernel module (as illustrated in Figure 4. Also, the prototype uses UDP tunnels in order to work correctly on an IP network.
In Figure 7, the internal steps of the service socket
API are illustrated. For svc request(), a lexer and
parser are used to interpret the service specification
string. The specification information is translated into
a request packet that is sent to the local Service Controller. The Service Controller makes a routing and
mapping decision to determine which services are processed locally and which are sent on to other service
We have implemented the network service architecture described on Emulab [28]. The following functionality and features are supported by this prototype:
• Service Nodes automatically determine their connectivity to neighboring nodes and report their
topology information (including estimated link
delays) to their designated service controller.
The only configuration information necessary at
startup is the IP address of the Service Controller.
• Service Controllers receive topology information
from the Service Nodes with their autonomous system. Where autonomous system boundaries are
crossed, Service Nodes from the other autonomous
system provide the IP address of their Service Con8
0
31
IP header
UDP header
6.
destination is next
service hop; source
is last service hop
flow ID
source node autonomous system ID
source node ID
source node port
source node IP
network service
header
data
application data
USAGE SCENARIOS
To illustrate the usefulness of our network service architecture, we discuss several usage scenarios. One of
them, an IPTV video distribution system, we have prototyped on Emulab.
6.1
Example Scenarios
Several examples illustrate the generality of a network
service architecture as we propose it. The corresponding end-to-end abstractions show that such functionality can be easily invoked by application:
• Example 1: Privacy and Authentication. To establish a secure connection, a privacy and authentication service can be employed. This service
specification can be expressed as:
Figure 8: Header Format of Data Packet.
controllers. Once the remainder of the request has been
processed (all the way to the receiving end-system), the
Service Controller returns the information about the
next hop to the sending end-system. Then a service
socket is established and returned to the application.
For svc send(), a UDP packet is created to be sent
to the next hop Service Node. The service header that is
added contains information about the flow that allows
the Service Node to correctly demultiplex the packet
and apply the correct network service. When receiving
a packet with svr recvfrom(), this header is stripped
away and solely the application data is delivered.
*:*>>encryption>>decryption
>>192.168.1.1:80
In this case, the application would not need to determine if such privacy and authentication is provided via transport layer security (e.g., SSL) or
network layer security (e.g., IPSec). Instead, simply the service functionality is specified. Note that
it is necessary to constrain the location of encryption and decryption to locally trusted nodes in the
sending and the receiving domain (as explained in
Section 4.1.5.
5.3 Header Format
• Example 2: Application-Layer Caching. A caching
service can be used to obtain static content without having to connect all the way to the original
server. A service specification for such a service
looks like this:
The headers format of a data packet in our prototype is shown in Figure 8. The IP and UDP header is
used to send packets to the next service hop. The network service header contains the information necessary
to implement network service functionality:
*:*>>cache(HTTP)>>192.168.1.1:80
• The flow identifier is used to identify the packet
and demultiplex it correctly. Flow identifiers are
assigned by the receiving Service Node and thus
can be chosen to be locally unique. On the Service
Node, they are translated to the identifier used by
the next Service Node (similar to MPLS).
In this scenario, the parameter HTTP informs the
caching service of the application layer protocol
that is used. The request for the caching service
can be made by the sender or the receiver (or even
the network service provider) as illustrated in Figure 5.
• The information about the source node (autonomous system, identifier, IP, port) is carried to
allow the receiving end-system to establish a duplex connection back to the sending end-system.
(The UDP header only carries information going
back to the last Service Node and thus cannot be
used for this purpose.)
• Example 3: Mutlicast. Multicast is a classic example of a function that is ideally performed in the
data path of routers (rather than in end-system
overlays). Network services can very easily implement this functionality and end-systems can easily
access it. For example:
• The data field carries data that is delivered to the
end-system application (or to an intermediate network service).
*:*>>multicast(192.168.1.1,192.168.2.17,
192.168.10.1)>>*:80
This example sends traffic to three different IP
addresses. To install a correct multicast tree,
the Service Controller simply determines the
destination path to all three addresses. Whenever
Note that network service headers are created and
removed automatically by the service socket API. Thus,
they are hidden from end-system applications.
9
they diverge, a multicast service is installed
and the service request is split accordingly and
forwarded downstream. Note that the destination address is ‘*’ since it depends on the
chosen path. Once only a single destination
is left, it is replaced by that IP address. We
also permit that different service specifications are provided for different IP addresses
(e.g., *:* >> multicast(192.168.1.1:80,
monitor(bandwidth) >> 192.168.2.17:5000)
transmits traffic to two destinations with different
ports and invokes a bandwidth monitor after
splitting off the path for 192.168.2.17).
be clearly seen, the transcoder reduces the data rate
of the transmitted video. Thus, it can be received
and displayed by a low-end client system. Note that
this transcoding occurs without support by the sender
and without affecting other branches of the multicast
connection. Also note that the packet rate is reduced
indicating that the transcoding operates across packet
boundaries. Also shown is the data rate at the receiver
that does not use transcoding. There the data rate corresponds to that of the sender (except for a few packet
losses).
This example and the general scenarios discussed
above illustrate the potential that our end-to-end service abstractions hold for making complex network services easily accessible and usable.
In all cases, the end-system application only needs to invoke a suitable service socket at connection setup time.
Once the connection is established, data is transferred
as in normal datagram sockets.
7.
SUMMARY
In this paper, we have presented a network service
architecture for the next-generation Internet. This architecture can be deployed on advanced programmable
(and virtualized) routers. The end-to-end abstractions
of this architecture allow applications to easily utilize
network services by providing a service specification
during connection setup. Data send and receive operations are based on well-understood datagram socket
operations. We have implemented a 60-node prototype
of this architecture on Emulab. We show results from
a video distribution scenario where a transcoding service can process packet payloads to adjust video size
for a thin client. We believe the presented architecture provides an important step towards making the
next-generation Internet functionally powerful without
exposing complex details to applications.
6.2 IPTV Video Distribution
To show results from a specific application scenario
that runs on our prototype platform, we consider a
video distribution scenario. In such a service, we may
have the following services:
• Multicast: As explained above, data may be sent
to multiple destinations. This service would be
requested by the sender of the video stream.
• Transcoding: Not all end-systems can receive
and display high-quality video (e.g., PDA or
cellphone). Thus, the receiver may request a
transcoding service that reduces the resolution of
the video. This service would be requested by
the receiver. In this example, we transcode from
HDTV (1080p) to H.264 (176×208 pixel for cell
phone display).
Acknowledgements
This material is based upon work supported by the
National Science Foundation under Grant No. CNS0626690.
• Monitoring: A network service provider may
choose to monitor video connections for bandwidth. This information could be used to manage
network resources to provide quality of service.
8.
Thus, this example consists of three services that are
specified by different parties and yields the following
service specification:
REFERENCES
[1] Anderson, T., Peterson, L., Shenker, S.,
and Turner, J. Overcoming the Internet
impasse through virtualization. Computer 38, 4
(Apr. 2005), 34–41.
[2] Baldine, I., Vellala, M., Wang, A.,
Rouskas, G., Dutta, R., and Stevenson, D.
A unified software architecture to enable
cross-layer design in the future internet. In Proc.
of Sixteenth IEEE International Conference on
Computer Communications and Networks
(ICCCN) (Honolulu, HI, Aug. 2007).
[3] Barbir, A., Reinaldo, P., Chen, R.,
Hofmann, M., and Hilarie, O. An
architecture for open pluggable edge services
*:*>>monitor(bandwidth)>>
multicast(192.168.1.1,video transcode
(1080p,H.264)>>monitor(bandwidth)
>>192.168.2.17)>>*:5000
The video is monitored and distributed to 192.168.1.1
and 192.168.2.17 at port 5000. For the latter destination, the video is transcoded from 1080p to H.264
and monitored again (to observe the bandwidth of the
reduced video).
Figure 9 shows the data (and packet) rate of video
traffic before and after the transcoding service. As can
10
8
2
6
1.5
4
1
2
0.5
0
0
50
100
150
0
200
3
data rate
packet rate
after transcoding
10
2.5
8
2
6
1.5
4
1
2
0.5
0
0
50
100
150
12
packet rate (kpps)
data rate (Mbps)
12
data rate (Mbps)
2.5
packet rate (kpps)
3
data rate
packet rate
at sender
10
0
200
3
data rate
packet rate
without transcoding
10
2.5
8
2
6
1.5
4
1
2
0.5
0
0
50
100
150
packet rate (kpps)
data rate (Mbps)
12
0
200
time(s)
Figure 9: Data Rate of Video Traffic at Sender, After Transcoding Service, and Without Transcoding.
[4]
[5]
[6]
[7]
[8] Clark, D. D. The design philosophy of the
DARPA Internet protocols. In Proc. of ACM
SIGCOMM 88 (Stanford, CA, Aug. 1988),
pp. 106–114.
[9] Coffield, D., and Shepherd, D. Tutorial
guide to Unix sockets for network
communications. Computer Communications 10,
1 (Feb. 1987), 21–29.
[10] Egevang, K. B., and Francis, P. The IP
network address translator (NAT). RFC 1631,
Network Working Group, May 1994.
[11] Feldmann, A. Internet clean-slate design: what
and why? SIGCOMM Computer Communication
Review 37, 3 (July 2007), 59–64.
[12] Fu, X., Shi, W., Akkerman, A., and
Karamcheti, V. CANS: composable, adaptive
network services infrastructure. In Proc. of the
3rd USENIX Symposium on Internet Technologies
and Systems (USITS) (San Francisco, CA, Mar.
2001), pp. 135–146.
[13] Ganapathy, S., and Wolf, T. Design of a
network service architecture. In Proc. of Sixteenth
IEEE International Conference on Computer
(OPES). RFC 3835, Network Working Group,
Aug. 2004.
Bavier, A., Bowman, M., Chun, B., Culler,
D., Karlin, S., Peterson, L., Roscoe, T.,
Spalink, T., and Wawrzoniak, M. Operating
system support for planetary-scale network
services. In Proceedings of the 1st Symposium on
Network System Design and Implementation
(NSDI ’04) (San Francisco, CA, Mar. 2004).
Bellman, R. On a routing problem. Quarterly of
Applied Mathematics 16, 1 (Jan. 1958), 87–90.
Bhatti, N. T., and Schlichting, R. D. A
system for constructing configurable high-level
protocols. In SIGCOMM ’95: Proceedings of the
conference on Applications, technologies,
architectures, and protocols for computer
communication (Cambridge, MA, Aug. 1995),
pp. 138–150.
Braden, R., Faber, T., and Handley, M.
From protocol stack to protocol heap: role-based
architecture. SIGCOMM Computer
Communication Review 33, 1 (Jan. 2003), 17–22.
11
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
Communications and Networks (ICCCN)
(Honolulu, HI, Aug. 2007), pp. 754–759.
Gu, X., Nahrstedt, K., and Yu, B.
SpiderNet: An integrated peer-to-peer service
composition framework. In Proc. of Thirteenth
IEEE International Symposium on
High-Performance Distributed Computing
(HPDC) (Honolulu, HI, June 2004), pp. 110–119.
Guha, S., and Francis, P. An end-middle-end
approach to connection establishment. In
SIGCOMM ’07: Proceedings of the 2007
conference on Applications, technologies,
architectures, and protocols for computer
communications (Kyoto, Japan, Aug. 2007),
pp. 193–204.
Huang, X., Ganapathy, S., and Wolf, T. A
distributed algorithm for network service
placement. In Proc. of Seventeenth IEEE
International Conference on Computer
Communications and Networks (ICCCN) (St.
Thomas, USVI, Aug. 2008).
Huang, X., Ganapathy, S., and Wolf, T. A
scalable distributed routing protocol for networks
with data-path services. In Proc. of 16th IEEE
International Conference on Network Protocols
(ICNP) (Orlando, FL, Oct. 2008).
Hutchinson, N. C., and Peterson, L. L. The
x-kernel: An architecture for implementing
network protocols. IEEE Transactions on
Software Engineering 17, 1 (Jan. 1991), 64–76.
Keller, R., Ramamirtham, J., Wolf, T.,
and Plattner, B. Active pipes: Program
composition for programmable networks. In Proc.
of the 2001 IEEE Conference on Military
Communications (MILCOM) (McLean, VA, Oct.
2001), pp. 962–966.
Lakshminarayanan, K., Stoica, I., and
Wehrle, K. Support for service composition in
i3. In Proc. of the 12th annual ACM international
conference on Multimedia (New York, NY, Oct.
2004), pp. 108–111.
Mogul, J. C. Simple and flexible datagram
access controls for UNIX-based gateways. In
USENIX Conference Proceedings (Baltimore,
MD, June 1989), pp. 203–221.
Rudra Dutta, G. N. R., Baldine, I., Bragg,
A., and Stevenson, D. The SILO architecture
for services integration, control, and optimization
for the future internet. In Proc. of IEEE
International Conference on Communications
(ICC) (Glasgow, Scotland, June 2007),
pp. 1899–1904.
Ruf, L., Farkas, K., Hug, H., and
Plattner, B. Network services on service
extensible routers. In Proc. of Seventh Annual
[24]
[25]
[26]
[27]
[28]
[29]
[30]
12
International Working Conference on Active
Networking (IWAN 2005) (Sophia Antipolis,
France, Nov. 2005).
Schmitt, M., Acharya, A., and Ibel, M.
Service Sockets: A uniform user-level interface for
networking applications. Tech. Rep. TRCS99-39,
University of California, Santa Barbara, Santa
Barbara, CA, Dec. 1999.
Tennenhouse, D. L., and Wetherall, D. J.
Towards an active network architecture. ACM
SIGCOMM Computer Communication Review 26,
2 (Apr. 1996), 5–18.
Turner, J. S., Crowley, P., DeHart, J.,
Freestone, A., Heller, B., Kuhns, F.,
Kumar, S., Lockwood, J., Lu, J., Wilson,
M., Wiseman, C., and Zar, D. Supercharging
PlanetLab: a high performance, multi-application,
overlay network platform. In SIGCOMM ’07:
Proceedings of the 2007 conference on
Applications, technologies, architectures, and
protocols for computer communications (Kyoto,
Japan, Aug. 2007), pp. 85–96.
Vellala, M., Wang, A., Rouskas, G. N.,
Dutta, R., Baldine, I., and Stevenson, D.
A composition algorithm for the SILO cross-layer
optimization service architecture. In In Proc. of
the Advanced Networks and Telecommunications
Systems Conference (ANTS) (Mumbai, India,
Dec. 2007).
White, B., Lepreau, J., Stoller, L., Ricci,
R., Guruprasad, S., Newbold, M., Hibler,
M., Barb, C., and Joglekar, A. An
integrated experimental environment for
distributed systems and networks. In Proc. of the
Fifth Symposium on Operating Systems Design
and Implementation (Boston, MA, Dec. 2002),
USENIX Association, pp. 255–270.
Wolf, T. Challenges and applications for
network-processor-based programmable routers.
In Proc. of IEEE Sarnoff Symposium (Princeton,
NJ, Mar. 2006).
Wolf, T. Service-centric end-to-end abstractions
in next-generation networks. In Proc. of Fifteenth
IEEE International Conference on Computer
Communications and Networks (ICCCN)
(Arlington, VA, Oct. 2006), pp. 79–86.