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 implementationsof a functionality without needing to change the applications. Using intermediate abstraction layers is an approach to break the dependency between applications and network protocols. Oneof 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

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 G-Lab 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

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. MethodsAs 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. NamingThe 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

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. RequirementsAn 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-to-end 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.

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:

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 index-based 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:

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 in-network 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

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 ResolutionA 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

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.

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.

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?

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 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 Initial name exchangeWhen the sender sends the first packet to the receiver it appends its own name as an IP-Option/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 thesame 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).

Figure 6. Protocol Overview.

2.7.4 Name formatNames can be provided in any of three ways.

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 selection Often today, the transport protocol is implied by the service in question.  How this is handled remains to be defined.  It is however likely that a default transport protocol can be provided depending on which service is requested.

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, Information-centric 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

[1] 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.

[4] 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-to-Network 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-ubillos- name-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-tsvwg-sctpsocket-25 (work in progress), January 2011.