The document summarizes different types of network application programming interfaces (APIs) that could be used for future internet architectures. It discusses APIs that use names instead of addresses, are independent of the underlying protocols, and allow applications to specify requirements instead of protocols. Specific APIs summarized include: 1) A recursive architecture API that uses recursive layers and a common interface between layers to provide quality of service across different network technologies. 2) An information-centric networking API that allows applications to access named data objects and leverage in-network caching for content distribution. 3) A requirements-based socket API that decouples applications from network architectures by allowing applications to specify requirements instead of protocols.

1. Network Application Programming Interfaces (APIs) for
Future Internet: Survey
Mahalakshmi Tarikere Devendrappa, Ashish Gowra Ravindra, Shahzeeb Palkkandy Kottothe.
Ilmenau University of Technology,
mahalakshmi.tarikere-devendprappa@tu-ilmenau.de,
ashish.gowra-ravindra@tu-ilmenau.de,
shahzeeb.palkkandy-kottothe@tu-ilmenau.de
Abstract: The existing application programming interface (API) between applications and the
network architecture is one reason that it is hard to deploy novel protocols into the network
architecture. Coupling between applications and underlying protocols makes it almost impossible
to change one without changing the other. Coupling can be loosened or resolved by not involving
applications in protocols implementation details but, only in functionality necessary to establish
a communication. This way underlying network can deploy novel or updated implementations
of a functionality without needing to change the applications. Using intermediate abstraction
layers is an approach to break the dependency between applications and network protocols. One
of the major goals in future internet architectures is to be flexible enough to adapt to
application’s requirements. In this paper, several API types are presented for applications and
network stacks and classified them according to their properties

2. 1 Introduction:
An increased public awareness of several critical shortcomings in terms of performance,
reliability, scalability, security and many other categories including societal, economical and
business aspects in current Internet technologies, has led to extensive research efforts. The term
Future Internet is generally used to refer these research activities on new architectures for the
Internet. Current APIs are one of the prime obstacles for innovation in the future Internet.
Existing APIs were made with the assumption that the Internet supports a limited number of
protocols and relies on applications to specify the exact protocol to use. The deployment of new
transport protocols such as SCTP, DCCP and new addressing schemes are hindered as an
application is obliged to specify the address type (IPv4 or IPv6). An application needs to be
modified if it wants to use TCP or UDP. Peer addressing and address-resolution are part of an
application, which makes an application address type dependent. Thus an application has to
select a particular addressing type such as IPV4 or IPV6. Different addressing types require
different socket so that there is a difference between IPv4 TCP socket structure and IPv6 TCP
socket structure and same is true for UDP.Many APIs are being developed to adapt to
heterogeneity of the networks. Name based socket APIs, Requirement based socket APIs, GENI,
Information-centric networks, Recursive Architecture, Protocol-Independent Internet Transport
API are few of them which are described further.
Our Future Internet provides three different interfaces to applications
Figure1:Overvie
w of our GLab Interface ISetup [5]
The first interface ISetup is used to start the interaction with a network stack. On the one hand, it
provides methods for announcing services, which should be available for others (PUBLISH). On
the other hand, others can use the interface to connect to these announced services
(SUBSCRIBE). In both cases, the methods are used to get references to instances supporting one
of the following interfaces. The second interface IRegistration is used to change requirements for
the announced service and to cancel it. In addition, it provides information about incoming
subscriptions. The third interface ISubscription is used to communicate with the service and the

3. peer using it, respectively. It allows sending and receiving of data either in stream or datagram
mode. In the following, the focus will be on the ISetup interface, since it is the most important
one for the interaction between network stacks and applications.
A. Methods
As mentioned before, the ISetup interface provides methods, which are used by an application to
start interaction with a network stack. An overview of them is given in Figure 1. This interface
provides the following two methods:
• IRegistration PUBLISH(Name, Requirement description): announces an application
service to a network stack, by specifying a name and requirements of the service for the
network. The network stack is made aware of the service and should provide other
members of the network access to this service. The name is basically treated as a label.
The announcement is represented by an instance supporting IRegistration (or a handle in
a procedural programming language). The requirements have to be satisfied by the
network for each peer, willing to use the service.
• ISubscription SUBSCRIBE(Name, Requirement description):establishes a communication
association to a service, which was published before. The name parameter defines the
service to talk with The name must match with the name handed over to the PUBLISH
method before. The requirements defines the characteristics of the communication
relationship the network has to provide. In contrast to the requirements in the PUBLISH
method, they are only valid for a single connection.
B. Call Sequence
A sequence of method calls for a typical client server scenario starts with the announcement of
the service. The server application calls PUBLISH in order to make its service available under a
name chosen by itself. This step is somehow comparable to BIND calls in today’s IP networks,
but binds a service to a name not an address and port. An association is started by a client
application with SUBSCRIBE. The client has to use the same name as the server application.
This step is comparable to today’s CONNECT calls with a different name semantic and
additional requirements the network has to fulfill. As a result, SUBSCRIBE will return a
reference to a ISubscription object. At the server side, the network will inform the server about
the new communication association. The server will get an ISubscription reference for the
communication association via its IRegistration interface as well. Now, both sides have
references to the communication association and can start to transfer data. On the client side, the
reference can be used to send its request to the server, which uses its reference to receive it. The
server will answer by sending data by using its ISubscription reference and the client will use its
reference to receive it. Finally, either the client or the server can cancel its ISubscription. The
cancellation will be propagated to its communication partner and invalidate its communication
association, too.
C. Naming
The most important goal of the API is to hide network and network stack specific issues from the
applications. In particular, that refers to the mapping from names to addresses and the selection
of an address space (like using IPv4 or IPv6 addresses). Both parts should not be anticipated by
applications. Consequently, applications must specify names in their own domain and based on

4. their own name space. We propose a globally unique naming scheme based on Uniform
Resource Identifiers (URIs). In order to allow different name spaces, we will use the scheme
given in URIs to distinguish between them (like mailto:// or file://).
D. Requirements
An application states its requirements explicitly in order to specify the characteristics of a
communication association. A requirement consists of an Effect linked by an Operator to an
Attribute. Effects describe the visible outcome of an operation of a building block or the
network. Effect is a neutral term: Encryption is an effect as well as delay. Through further
specification it becomes clear whether something is being provided or wished to be avoided. For
example, an application can request a Packet Loss of 0, whereas a certain network connection
could provide a Packet Loss of 5% average. Attributes quantify or qualify effects and can be
divided into two distinct parts: Inherent and qualitative. For inherent attributes, it must be clear
to decide whether a certain property can fulfill a requirement or not (e.g.,200ms). An inherent
attribute will normally be expressed by a number, however, functional requirements via boolean
values are also possible, e.g. VirusScan == true.
2 Types of APIs:
2.1 Recursive Architecture:
Providing quality of service for a packet-oriented communication network is a
challenging problem even if only a single technology is considered. For inter-networks such as
the Inter-net, the task gets even more problematic. Since an inter-network is a network of
networks, it connects networks using different technologies like Ethernet, WLAN or UMTS,
with transit networks in-between. In a realistic scenario, an end-to-end connection has to cross
multiple networks such as a local area network (LAN) at the sender as well as on the receiver
side with transit networks of different technologies in between. In addition to the various
technologies possibly in use on the LAN side, the segmentation of the Internet into autonomous
systems introduces additional complications when attempting to establish QoS-enabled flows for
end-to-end connections. Each autonomous system might have different policies for handling QoS
in place and might use different intra-network techniques to implement it. However, an end-toend connection can only be provided, if the QoS requirements are handled by all networks,
which forward packets of this flow. Any solution supporting the technological manifoldness of
the networks, has to meet the following requirements[6]:
•
Provide QoS for different intra-network layers and signal the end-to-end connection on
the inter-network layer.
•
Ensure the conformance between the possible QoS classes of the different intra-network
layers and between the various autonomous systems.
•
Enable schemes allowing each application to be as-signed to the intended traffic class or
alternatively provide a common interface allowing each application to signal its QoS
requirements on the network.

5. To face the problems on the inter-network layer, there are already solutions available, which can
be divided into differentiated services (DiffServ) and integrated services (IntServ). Since the
Internet as a large network consists of different autonomous systems, the preservation of the
conformance between the different network parts regarding the interpretation of the QoS classes
is the most challenging problem. Therefore here we define an architecture comprising recursive
layers with a single interface between these layers and between layers and applications. It is
evaluated based on two example layers, whereas the focus of the evaluation is on the QoS
aspects. Our key contribution is to present not a cross-layer but a recursive layer interface.
In summary, today’s solution for providing QoS faces problems regarding scalability and
flexibility. We propose a solution that exploits the flexibility of recursive layers with a novel
solution for the implementation of each layer. In particular, we propose employing “Forwarding
on Gates” (FoG) for the Internet layer and the “Traffic Engineering Middleware for Ethernet”
(TEME) at the intra-network layer. Figure 2 shows the logical node architecture with both layers.
Due to the recursive nature, there might be some more layers handling, e.g., overlay aspects.
Since each layer provides the same functionality to the layer above, all layers can use exactly the
same interface. It is shown as dotted line in Figure. However, the interface has to be designed in
a way that it hides the details of a layer and enables a broad range of design and implementation
varieties for layers.
Figure 2:Recursive Layers with APIs in between[6].
The recursive layer approach defines layers not based on functionality but based on scope. Each
layer has an area, for which it is responsible. For example, the lowest layer is responsible for a
link. The next higher layer is responsible for an intra-network, while the highest one is
responsible for the whole Internet. Since the layers differ only in scope, each layer provides the
same functionality such as relaying packets and performing routing. Furthermore, it has to
manage its resources including congestion and flow control. Here we follow this approach using
recursive functions to design API’s.
2.2 Inter-Network Layer FoG:

6. For the inter-network layer, which handles the end-to-end aspects, we propose to use FoG. Its
main idea is to represent available links and their capabilities as unidirectional functional blocks,
called gates. End-to-end connections between two higher layers are constructed by concatenating
multiple gates to a chain of functional blocks. Which blocks are combined into a chain depends
on the requirements of a connection. As shown, this system can represent QoS guarantees of the
IntServ model and prioritizations of the DiffServ model using gates. This enables a unified
handling of both models during packet for-warding. Forwarding in FoG is based on an indexbased forwarding approach as used by MPLS or Pathlet. FoG’s route definition differs from
these protocols by allowing route segments. A FoG route is constructed using two types of
segments. First, an explicit route segment contains a stack of indi-ces defining an explicit
sequence of gates. It is comparable to stacked LSP labels in MPLs. Second, a destination route
segment defines an address and the requirements of intermediate nodes of a route[6].
The flexibility to construct a route out of these two types enables a broad range of network
setups. In particular, it allows the movement of some states from the node providing a gate to the
node using the gate. The latter can specify gates required for connections directly in the route
and does not rely on states stored on the node providing the gates. This approach can be used to
reduce the number of states at ingress routers. In addition to the reduction mentioned in the
previous part, which uses aggregation, FoG enables the movement of states as an orthogonal
solution to the scalability problem.
FoG provides access to applications via the recursive interface described before. Moreover, it
uses the recursive interface in order to access lower layers. A gate representing the transmission
of packets to another physical node uses the connect function in order to setup the
communication channel through the lower layer. Their requested capabilities such as minimal
bandwidth and maximum delay are handed over to the lower layer as the connect requirements.
2.3 A Common API for Transparent Hybrid Multicast:
Group communication services exist in a large variety of flavours, and technical implementations
at different protocol layers. Multicast data distribution is most efficiently performed on the
lowest available layer, but a heterogeneous deployment status of multicast technologies
throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to
write an application that runs everywhere and at the same time makes use of the most efficient
multicast service available in the network. Facing robustness requirements, developers are
frequently forced to using a stable, upper layer protocol controlled by the application itself.
[8]Here we describe a common multicast API that is suitable for transparent communication in
underlay and overlay, and grants access to the different multicast flavours. It proposes an
abstract naming by multicast URIs and discusses mapping mechanisms between different
namespaces and distribution technologies. Additionally, it describes the application of this API
for building gateways that interconnect current multicast domains throughout the Internet.
2.4 Information-Centric Networking:

7. The information-centric networking (ICN) concept is a significant common approach of several
future Internet research activities. The approach leverages in-network caching, multiparty
communication through replication, and interaction models decoupling senders and receivers.
The goal is to provide a network infrastructure service that is better suited to today’s use (in
particular. content distribution and mobility) and more resilient to disruptions and failures. The
ICN approach is being explored by a number of research projects. We compare and discuss
design choices and features of proposed ICN architectures, focusing on the following main
components: named data objects, naming and security, API, routing and transport, and caching.
We also discuss the advantages of the ICN approach in general [3].
The increasing demand for highly scalable and efficient distribution of content has motivated the
development of future Internet architectures based on named data objects (NDOs), for example,
web pages, videos, documents, or other pieces of information. The approach of these
architectures is commonly called information centric networking (ICN). In contrast, current
networks are host-centric where communication is based on named hosts, for example, web
servers, PCs, laptops, mobile handsets, and other devices. The ICN architectures leverage innetwork storage for caching, multiparty communication through replication, and interaction
models that decouple senders and receivers. The common goal is to achieve efficient and reliable
distribution of content by providing a general platform for communication services that are today
only available in dedicated systems such as peer-to peer (P2P) overlays and proprietary content
distribution networks.
2.5 Requirement-Based Socket API:
A requirements based API is proposed here to decouple applications from underlying network
architectures. It also encourages to seamlessly switch between different network architectures
which will help to deploy novel network architectures without having the need to change the
applications or the currently used API. Requirements are an abstraction which can be dealt by
various diverse architecture. Address resolution is not seen as a responsibility of an application.
An application will rather use homogeneous URI addressing; further address resolution is taken
care by the underlying networks architectures, resolution of a address may differ from one
architecture to another[4].
Current applications are tightly coupled with the given protocols, though they only care about its
connectivity demands are fulfilled. A Requirements-based API will alleviate the developer from
choosing a protocol or even a protocol specification. Instead, requirements will be communicated
to the underlying network architecture. Using these requirements, explicit connection
characteristics are requested for the new communication relationship. Requirements are specified
in terms of effects/capabilities, an effect is a visible outcome of functionality such as flow
control functionality provides effect of transmission rate adaptation between two parties.
2.5.1 Architecture

8. Figure 3: Architecture [4].
This API proposal enables multiple architectures to work in parallel without need of adapting an
application with respect to an architecture. Nevertheless it stimulates the need of an additional
component in the current Internet, which will translate the incoming requirements (i.e.
represented as capabilities) to match with an appropriate protocol stack (e.g. TCP/IP, UDP/IP).
The abstraction of requirements in terms of capabilities enables to use any of underlying
architecture without changing the application however architecture must have comprehension of
the incoming requirements.
2.5.2 Address Resolution
A task that is not necessarily specific to an API approach is the task of how to name a particular
service and how the naming resolution is to be done. Traditionally, socket addresses would be
packed using a struct sockaddr C structure and the inet_ntoa function call. This approach is
likely to be obsolete in a Future Internet architecture, as IPv4 or IPv6 addresses will not remain
the only (de-facto) standard addressing scheme. Keeping in mind that the network stack should
now also take tasks upon itself which were not initially included in the Berkeley Socket API but
instead needed to be built on top of it — e.g., streaming controls — the naming scheme of today
that focuses on protocol addresses does not work anymore. Instead, a more general naming
scheme must be developed and advised. We propose a hierarchical naming scheme that is
loosely based on URIs [11]. Here, IP addresses can still be named using a resource locator like
ip4://172.19.32.1. However, the goal of the new naming scheme is to name not addresses,
machines, or multicast groups, but in general establish a communication relationship to a
resource that is accessible through the network. As such, video streams can as well be named via
video://some-video, even by supplying additional parameters like a certain timestamp in the
video. This will of course make the introduction of an address resolution system an hard
requirement for a Future Internet architecture using this naming scheme. But a current operating
system installation already comes with several name resolution systems installed and enabled by
default. The most widely known is DNS, the Domain Name System [12]. A UNIX system carries
other means of resolution which can be transparently enabled or disabled using the
/etc/nsswitch.conf configuration files. They are either plain text files, simple databases, access
directory servers or make use of different means of resolution altogether. Also, Windows hosts

9. employ similar means of name resolution. Thus, the question of how to resolve names is already
answered on any of today’s operating systems. Also considerations of where this resolution takes
place — i.e., kernel space vs. user space — are also solved. The same design principles and
considerations apply to name resolution in a Future Internet architecture. The difference lies only
in the fact that name resolution is now no longer distinct part in an ecosphere of mechanisms
used in conjunction, but integrated into the network stack and its usage hidden from the
application developer.
2.5.3
Types of Requirements
Before identifying the types of requirements it worth to describe what requirement real is so that
Requirements are one of two parameters an API approach needs. While the naming parameter
(explained in the preceding subsection) specifies what service is accessed, the requirements
parameter specifies how. Such requirements can be abstract, like “ciphering,” or specific, like
“delay lower than 200ms.” Requirements consist of three parts: An effect, an operator and an
attribute. Effects denote certain characteristics, e.g. delay. It is important to emphasize that these
characteristics are neither “good” nor “bad” but denote the outcome of an operation. Effect is
thus a neutral term. “Delay” is an effect just as “packet loss” or “encryption” is an effect. To
quantify an effect, attributes are used. An attribute is a numeric value like “200ms.” Effects and
attributes are linked via operators, such as “equals,” “greater than,” etc. One way to identify the
basic requirements list is to review contemporary transport protocol stacks and their provided
functionality. In PIAPI [10], analyzing of transport protocols such as SCTP, TCP, DCCP, UDP
has been carried out. Provided list of PIAPI can be seen as an initial step towards finding
appropriate requirements for the purpose, however, proposed names in the list are function
oriented on the other hand we see the requirements in terms of effect (i.e. outcome/resultant of a
functionality) which can be asked from an application. Following are the provided capabilities
from the PIAPI list.
• Flow Characteristic: Combined service of flow and congestion control
• Application PDU bundling: Waiting for more messages and to send them all together
• Error Detection: Mechanism to detect and correct errors
• Reliability: Data delivery with no loss
• Delivery Order: To ensure to receive messages in an exact same order in which they
have been sent
• Multi-Homing: To support multiple network interfaces at a single machine
Granularity of capabilities is not a trivial challenge and it may vary from domain to domain.
Why should congestion control and flow should be defined in a single effect? It is a valid
argument that in all current implementation they have been placed together and what if in the
future that the new protocols will be developed where those effects will be implemented
independent of each other, it would simply outdate the defined diction for the effects. Best
possible granularity will be where implementation of effects can be independent of each other,
thus an effect can be implemented without being dependent on other protocols’ implementation.
If incongruous granularity will trigger the need to modify the capabilities list very often so that it
may trigger to accommodate the outdated applications too as they might be using the wrong
diction for the given effect or it would require to have redundancy (i.e. simply adding new
effects without deleting or altering the older ones) of terms with composed and atomic effects.

10. In fig. 4, list of minimum set of effects is presented. Provided effects in the list are viewed from a
consumer (e.g. an application, a user) perspective, an application should not be concerned if an
underlying network architecture uses delivery type either packet or stream, but it should concerns
about if data can be securely or error free transmitted. Following is the explanation of some of
the given effects.
Figure 4:Effects requested from user /application
•
•
•
•
•
•
Authentication: It is requested from an application or a user, in case it needed to
authenticate the communicating partner. It should be clear that there are two aspects of
authentication, one to authenticate oneself and one to authenticate the communicating
partner. It is highly unlikely that a request will be made to authenticate oneself. So that
only authentication of a communication partner is being addressed here.
Packet Boundary Preservation: An Application or a user doesnt care about that if data is
delivered in datagrams or in a stream , but it would be required from some applications
that packet boundary is preserved and recovered at the other end. If no boundary is
defined then it can behave like a stream-oriented communication.
Error Ratio: It defines the error ratio even after correcting the error, as it is not possible
to assure an entirely error free transmission. So that the name is chosen to give the
freedom that how much error is corrected.
Traffic Prioritization: This functionality is asked by an application which is dealing with
more than one kind of traffic, it is important to make it clear that an application doesnt
have any influence on external traffic (i.e. traffic from other applications or users), so
that the application may specify which kind of its own traffic it wants to prioritize.
Loss Ratio: This functionality covers reliability provided by TCP. The name has been
chosen because of introduction of partial reliability from SCTP protocol stack, where
number of attempts or time-out period can be specified before packet is stopped to be
retransmitted. As to say, it is unlikely to be possible to have full reliability, thus loss ratio
is used to define the ratio of the data loss in the communication.
Data Duplication Avoidance: This functionality is used by the application which is not
able to deal with duplicated data itself.

11. Classification, shown in fig. 5, encourages the separation of concern. It is unlikely that an
application or user will be interested in the functionality such as data reduction, connection
management, loop avoidance. The shown functionalities in fig. 5 are of no importance for an
application but many of them are essential for a communication such as addressing or
connection management. Hence extra policies or requirements from an administrator or a
network are needed, classification helps to identify the related functionalities for an
administrator and a network.
Fig. 5: Effects: Application/User should not care about
2.6 Protocol-Independent Internet Transport API :
Let us assume that UDP-Lite, SCTP and DCCP get deployed as common transport protocols,
right next to TCP and UDP, available to everyone. Then, consider the choices that application
programmers face: SCTP with partial reliability, using multiple streams or only one stream
across an association? Or no reliability at all? But this is also what DCCP provides – however,
DCCP also has various forms of congestion control. Should we pick TCP-like or TFRC
congestion control? If we pick TCP-like congestion control, is it better to use DCCP or SCTP?
DCCP has receiver feedback with various drop codes, and ACK congestion control. SCTP has
partial reliability with a timer. What is more important for us? Do we want a checksum for our
data? If not, would it be even better to use UDP-Lite and take care of congestion control in the
application? Given that these protocols are new and experimental and might often not even be
available from one Internet endpoint to the other. The example given above is no exaggeration:
DCCP does not have a standardized API yet. It seems clear that we should at least try to simplify
access to these protocol’s mechanisms if we ever want to see them broadly used. As a part of this
simplification, and as an element of abstraction that has the potential to enable gradual
deployment of new and innovative transport mechanisms, we should first of all hide the
protocols themselves: why should an application programmer be even confronted with a decision
between, e.g., SCTP and TCP, as opposed to having a system that automatically makes the best
possible choice from the services that it has available?

12. Table 1:Overview of Transport APIs [9].
All of these above mentioned APIs are rather sophisticated, and the more abstract ones are
generally more complex.
2.7 Name-based sockets:
Name-based sockets allow application developers to refer to remote hosts (and it self) by name
only, passing on all IP (locator) management to the operating system. Applications are thus
relieved of re-implementing features such as multi-homing, mobility, NAT traversal, IPv6/IPv4
interoperability and address management in general. The operating system can in turn re-use the
same solutions for a whole set of guest applications. Name- based sockets aims to provide a
whole set of features without adding new indirection layers, new delays or other dependences
while maintaining transparent backwards compatibility. Name-based sockets provide a unified
interface which caters to the application developers who wish to simply open up a
communication to a remote host by its name and have operating system perform the management
of locators.it does so by providing a new address family (AF_NAME)which allows the
developers to use a name instead of an IP(or other locator).
2.7.1 Motivation
Network communication has for very long been based on the assumption that applications
should deal with the IP (locator) management. This is based on the legacy notion that an IP does
not change during a session and that a session is a communication between two given IPs
(locators). This situation has changed, locators change during a session, and a device/host might
have multiple locators, hosts may be behind NA(P)Ts or be on different locator domains (e.g.
IPv4/IPv6).Today, this is mostly left to the individual applications to solve. This adds
complexity to the applications making it a challenge in it self just to meet the networking
demands of applications.Name-based sockets aims to fix this by pushing the locator management
to the operating system, without introducing any new limitations or delays.
By approaching the problem at the socket() level, existing abstraction frameworks can easily
benefit from a change. By allowing the existing abstractions to simply pass along the name the
whole way down to the socket() call, the abstraction or whole framework are able to benefit by
name-based sockets.
2.7.2 Protocol Overview

13. Name-based sockets work by performing a name exchange in the beginning of a
communication. It does this in an non-blocking way. In practice what happens is that the first
few packets are exchanged in a normal legacy fashion. However, to these packets, extra
information about the corresponding hosts names are piggy-backed. If a name exchange is
successful, the extra features provided by name-based sockets are enabled. If the exchange does
not succeed, normal legacy communication continues unaffected. The name of each host is either
its FQDN, its IP in IPv6.arpa format or an arbitrary nonce. It may or may not be authenticated.
In the ordinary case, the name is not authenticated, thus the receiver does not need to perform a
reverse or forward lookup, hence not adding any further delays to the first packet(s). The
motivation for this is to avoid any additional "first-packet" delays. Once the name exchange has
been performed successfully the complete feature set will be made available to the
communication automatically.The expected API for a socket using AF_NAME is the same as for
e.g. TCP (SOCK_STREAM). This is also the case for SOCK_DGRAM and similar protocols,
for all practical purposes, the functionality remains unchanged, however, as state is created in
both ends, connection oriented semantics are more intuitive.
2.7.3 the sender sends the first
When Initial name exchange packet to the receiver it appends its own name as an IPOption/IPv6-Extension header. It repeats this for a predefined amount of time or packets. On
the receiving end, if the receiver supports name-based sockets it appends its own name in the
same fashion for a predefined amount of time or packets. Should the receiver not be able to
interpret the name, the option/extension header is ignored and the legacy communication
precedes as normal.This kind of name exchange has two consequences. First and foremost that
there are no extra delays on the initial packets. Secondly that the complete feature set provided
by name based sockets will not be available until a few packets have been exchanged.
In figure 1 the exchange is depicted. The first packet from the sender has its own name
appended to it. The next few packets sent will also have the name appended to it for a
predefined number of packets (X in the figure) or until a reply including a name extension
is received. On the receiving end, should an incoming packet have a name extension, the
receiver begins to append its own name to the sent packets. It does so for a predefined number
of packets (X in the figure).

14. Figure 6. Protocol Overview.
2.7.4 Name formatprovided in any of three ways.
Names can be
•
•
•
FQDN as The Fully Qualified Domain Name of the host
ip6.arpa as Using one of the hosts interfaces addresses as a name.
Nonce as A one-use only session identifier.
2.7.5 Transport transport protocol is implied by the service in question. How this is handled
Often today, the selection
remains to be defined. It is however likely that a default transport protocol can be provided
depending on which service is requested.

15. 3 Future Work
It is necessary to develop a translator to map those requirements with a protocol stack in the
current Internet architecture or a service in a future internet architecture. The functional units
will also have to be described along with their relationships and dependencies. This will lead to
the creation of a Domain Specific Language. Also, the URI-alike hierarchical scheme that is used
for naming needs to be specified in more detail. More components will want to interact with the
OS’s network subsystem, like the system administrator or the network hardware. Thus, a System
Programming Interface will also be needed in the future. The automatic multi-streaming
behaviour should be investigated; we also need to think in detail about events and notifications
for our protocol independent socket API which we just have started to implement. There might
be services which may be useful for some applications and hence lead to the development of new
protocols or protocol extensions.
4 Conclusion
Coupling between applications and underlying protocols makes it almost impossible to change
one without changing the other as in case of present internet. In order to deploy a new protocol in
the Internet architecture, it is not enough just to change the application but it also requires
modifying the API or using another API so that a user can unveil its intention to use the newly
deployed protocol. Coupling can be loosened or resolved by not involving applications in
protocols implementation details but, only in functionality necessary to establish a
communication. Adaptation of the current network API can be seen as the first step towards the
transition, as the API is the only point of contact for an application to reveal its communication
requirements to a network architecture. Many APIs are being developed to adapt to heterogeneity
of the networks. Name based socket APIs, Requirement based socket APIs, GENI, Informationcentric networks, Recursive Architecture, Protocol-Independent Internet Transport API are few
of them.
5 Contributions
Ashish Gowra Ravindra-,Student number-51405, section 2.2,2.2.
Mahalakshmi tarikere-devendprappa, Student number-51412, section 2.3,2.4.
Shahzeeb Palkkandy Kottothe,Student number-51413 ,section 2.5,2.6,2.7.
6
References
Sebastian Meiling, Dominik Charousset, Thomas C. Schmidt and Matthias W¨ahlisch,
“System-assisted Service Evolution for a Future Internet– The H8Mcast Approach to
Pervasive Multicast”,2010.
[2] Denis Martin, Hans Wippel, Helge Backhaus , “A Future-Proof Application-to-Network
Interface”,2011.
[3] Bengt Ahlgren, Christian Dannewitz, Claudio Imbrenda, Dirk Kutscher, and Börje
Ohlman, “A Survey of Information-Centric Networking”,2012.
[1]

16. Abbas Ali Siddiqui, Paul Mueller, “A Requirement-Based Socket API for a Transition to
Future Internet Architectures” ,2012.
[5] Florian Liers, Thomas Volkert, Denis Martin, Helge Backhaus, Hans Wippel, Eric MSP
Veith, Abbas Ali Siddiqui, Rahamatullah Khondoker: “GAPI: A G-Lab Application-toNetwork Interface “, 11th Würzburg Workshop on IP: Joint ITG and Euro-NF Workshop
"Visions of Future Generation Networks" (EuroView2011) , Würzburg Germany, August
2011.
[6] Florian Liers, Markus Hager, Sebastian Schellenberg, Jochen Seitz: “Recursive Layering
of Forwarding on Gates and Traffic Engineering Middleware for Ethernet”, International
Conference on Information Networking 2013 (ICOIN 2013), Bangkok, Thailand, January
2013.
[7] J. Ubillos ,M. Xu, Z. Ming, C. Vogt, “Name-based sockets architecture(draft-ubillosname-based-sockets-03)”,September 17,2010.
[8] M.Waehlisch, T C.Schmidt,S.Venaas,”A common API for Transparent Hybrid
Multicast(draft-waehlisch-sam-common-api-06)”,March 07,2011.
[9] Michael Welzl,Stefan Jorer,Stein Gjessing” Towards a Protocol-Independent
Internet Transport API”,2011.
[10] Stein Gjessing Michael Welzl, Stefan Joerer,” Towards a protocol independent
internettransport api”, Communications Workshops (ICC),2011 IEEE International.
[11] T. Berners-Lee, R. Fielding, and L. Masinter. Rfc 3986,” Uniform
resource identifier (uri)”, Generic syntax, 2005.
[12] P. V. Mockapetris. “Domain names - implementation and specification”,1987
[13] R. Stewart, K. Poon, M. Tuexen, V. Yasevich, and P. Lei, “Sockets API Extensions for
Stream Control Transmission Protocol (SCTP),” Internetdraft draft-ietf-tsvwgsctpsocket-25 (work in progress), January 2011.
[4]