| 1. |
- Bozakov, Zdravko, et al.
(författare)
-
Deliverable D2.1 - First Version of Low-Level Core Transport System
- 2016
-
Rapport (refereegranskat)abstract
- This document presents the first version of the low-level Core Transport System in NEAT, to be used for development of a reference implementation of the NEAT System. The design of this core transport system takes into consideration the Transport Services and the API defined in Task 1.3 and in close coordination with the overall architecture (Task 1.2). To realise the basic Transport Services provided by the API, a set of low-level transport functionalities has to be provided by the NEAT core transport system. These functionalities take the formof several building blocks, or NEAT Components, each representing an associated implementation activity. Some of the components are needed to ensure the basic operation of the NEAT System—e.g., a NEAT Flow Endpoint, a callback-based NEAT API Framework, the NEAT Logic and the functionality to Connect to a name. Some other components are needed to ensure connectivity usingMiddlebox Traversal techniques (e.g., TURN), discovery of path support for different transport protocols using Happy Eyeballs mechanisms, offering end-to end Security (e.g., (D)TLS over transport), gather statistics for the users or system administrators, and the ability to apply different policies in order to influence the decision-making process of the transport system. This document describes each of these building blocks and related design choices.
|
|
| 2. |
- Fairhurst, Gorry, et al.
(författare)
-
Deliverable D1.1 - NEAT Architecture
- 2016
-
Rapport (refereegranskat)abstract
- Ossification of the Internet transport-layer architecture is a significant barrier to innovation of the Internet. Such innovation is desirable for many reasons. Current applications often need to implement their own mechanisms to receive the transport service they need, but many do not have the breadth of adapting to all possible network characteristics. An updated transport architecture can do much to make the Internet more flexible and extensible. New ground-breaking services often require different or updated transport protocols, could benefit from better signalling between application and network, or desire a more flexible choice of which network path is used for which traffic. This document therefore proposes a new transport architecture. Such architecture lowers the barrier to service innovation by proposing a “transport system”, the NEAT System, that can leverage the rich set of available transport protocols. It paves the way for an architectural change of the Internet where new transport-layer services can seamlessly be integrated and quickly made available, minimising deployment difficulties, and allowing Internet innovators to take advantage of them wherever possible. The document provides a survey of the state-of-the-art to identify the architectural obstacles to, and opportunities for, evolution of the transport layer. It also details a set of general requirements for a new transport architecture. This new architecture is motivated by a set of use-cases, followed by a description of the NEAT architecture for a transport system, designed to permit applications to select appropriate transports based on their needs and the available transport services.
|
|
| 3. |
- Grinnemo, Karl-Johan, 1968-, et al.
(författare)
-
Deliverable D3.1 - Initial Report on the Extended Transport System
- 2017
-
Rapport (refereegranskat)abstract
- The NEAT System offers an enhanced API for applications that disentangles them from the actual transport protocol being used. The system also enables applications to communicate their service requirements to the transport system in a generic, transport-protocol independent way. Moreover, the architecture of the NEAT System promotes the evolution of new transport services. Work Package 3 (WP3) enhances and extends the core parts of the NEAT Transport. Efforts have been devoted to developing transport-protocol mechanisms that enable a wider spectrum of NEAT Transport Services, and that assist the NEAT System in facilitating several of the commercial use cases. Work has also started on the development of optimal transport-selection mechanisms; mechanisms that enable for the NEAT System to make optimal transport selections on the basis of application requirements and network measurements. Lastly, another research activity has been initiated on how to use SDN to signal application requirements to routers, switches, and similar network elements. This document provides an initial report on all these WP3 activities—both on completed and on near-termplanned work.
|
|
| 4. |
- Khademi, Naeem, et al.
(författare)
-
Deliverable D2.2 - Core Transport System, with both Low-level and High-level Components
- 2017
-
Rapport (refereegranskat)abstract
- This document presents the core transport system in NEAT, as used for development of thereference implementation of the NEAT System. The document describes the componentsnecessary to realise the basic Transport Services provided by the NEAT User API, with thedescription of a set of NEAT building blocks and their related design choices. The designof this core transport system takes into consideration the Transport Services and the API(defined in Task 1.3) and in close coordination with the overall architecture (Task 1.2).To realise the Transport Services provided by the API, a set of transport functionalitieshas to be provided by the NEAT Core Transport System. These functionalities take the formof several building blocks, or NEAT Components, each representing an associated implementationactivity. Some of the components are needed to ensure the basic operation ofthe NEAT System—e.g., a NEAT Flow Endpoint, a callback-based NEAT API Framework, theNEAT Logic and the functionality to Connect to a name. Additional components are neededfor: (a) ensuring connectivity, by means of mechanisms for discovery of path support fordifferent protocols; (b) supporting end-to-end security; (c) the ability to apply differentpolicies to influence the decision-making process of the transport system; (d) providingother important functionalities (e.g., a user-space SCTP stack, or gathering statistics forusers or system administrators).This document updates Deliverable D2.1; in particular, the descriptions of NEAT componentspresented here correspond to the implementation status at the time of writing,and as such they replace those in D2.1.
|
|
| 5. |
- Khademi, Naeem, et al.
(författare)
-
Deliverable D2.3 - Final Version of Core Transport System
- 2017
-
Rapport (refereegranskat)abstract
- This document presents the core transport system in NEAT, as used for development of the reference implementation of the NEAT System. The document describes the components necessary to realise the basic Transport Services provided by the NEAT User API, with the description of a set of NEAT building blocks and their related design choices. The design of this core transport system, which is the final product ofWork Package 2, is driven by the Transport Services and API design from Task 1.4, and in close coordination with the overall NEAT architecture defined in Task 1.2. To realise the Transport Services provided by the API, a set of transport functions has to be provided by the NEAT Core Transport System. These functions take the form of several building blocks, or NEAT Components, each representing an associated implementation activity. Some components are needed to ensure the basic operation of the NEAT System—e.g., a NEAT Flow Endpoint, a callback-based NEAT API Framework, the NEAT Logic and the functionality to Connect to a name. Additional components are needed for: (a) ensuring connectivity, by means of mechanisms for discovery of path support for different protocols; (b) supporting end-to-end security; (c) the ability to apply different policies to influence the decision-making process of the transport system; (d) providing other important functionalities (e.g., a user-space SCTP stack, or gathering statistics for users or system administrators). This document updates Deliverable D2.2; in particular, the descriptions of NEAT components presented here correspond to their implementation status by the end of WP2, and as such they supersede those in D2.2.
|
|
| 6. |
- Papastergiou, Giorgos, et al.
(författare)
-
De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives
- 2017
-
Ingår i: IEEE Communications Surveys and Tutorials. - : IEEE. - 1553-877X. ; 19:1, s. 619-639
-
Tidskriftsartikel (refereegranskat)abstract
- It is widely recognized that the Internet transport layer has become ossified, where further evolution has become hard or even impossible. This is a direct consequence of the ubiquitous deployment of middleboxes that hamper the deployment of new transports, aggravated further by the limited flexibility of the application programming interface (API) typically presented to applications. To tackle this problem, a wide range of solutions have been proposed in the literature, each aiming to address a particular aspect. Yet, no single proposal has emerged that is able to enable evolution of the transport layer. In this paper, after an overview of the main issues and reasons for transport-layer ossification, we survey proposed solutions and discuss their potential and limitations. The survey is divided into five parts, each covering a set of point solutions for a different facet of the problem space: (1) designing middlebox-proof transports; (2) signaling for facilitating middlebox traversal; (3) enhancing the API between the applications and the transport layer; (4) discovering and exploiting end-to-end capabilities; and (5) enabling user-space protocol stacks. Based on this analysis, we then identify further development needs toward an overall solution. We argue that the development of a comprehensive transport layer framework, able to facilitate the integration and cooperation of specialized solutions in an application-independent and flexible way, is a necessary step toward making the Internet transport architecture truly evolvable. To this end, we identify the requirements for such a framework and provide insights for its development
|
|
