SwePub
Sök i SwePub databas

  Utökad sökning

Träfflista för sökning "WFRF:(Mangiante Simone) "

Sökning: WFRF:(Mangiante Simone)

  • Resultat 1-8 av 8
Sortera/gruppera träfflistan
   
NumreringReferensOmslagsbildHitta
1.
  • Bozakov, Zdravko, et al. (författare)
  • A NEAT framework for enhanced end-host integration in SDN environments
  • 2017
  • Ingår i: 2017 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN). - : IEEE. - 9781538632857
  • Konferensbidrag (refereegranskat)abstract
    • SDN aims to facilitate the management of increasingly complex, dynamic network environments and optimize the use of the resources available therein with minimal operator intervention. To this end, SDN controllers maintain a global view of the network topology and its state. However, the extraction of information about network flows and other network metrics remains a non-trivial challenge. Network applications exhibit a wide range of properties, posing diverse, often conflicting, demands towards the network. As these requirements are typically not known, controllers must rely on error-prone heuristics to extract them. In this work, we develop a framework which allows applications deployed in an SDN environment to explicitly express their requirements to the network. Conversely, it allows network controllers to deploy policies on end-hosts and to supply applications with information about network paths, salient servers and other relevant metrics. The proposed approach opens the door for fine grained, application-aware resource optimization strategies in SDNs
  •  
2.
  • 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.
  •  
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.
  • Khademi, Naeem, et al. (författare)
  • NEAT: A Platform- and Protocol-Independent Internet Transport API
  • 2017
  • Ingår i: IEEE Communications Magazine. - : IEEE Communications Society. - 0163-6804 .- 1558-1896. ; 55:6, s. 46-54
  • Tidskriftsartikel (refereegranskat)abstract
    • The sockets Applications Programming Interface (API) has become the standard way that applications access the transport services offered by the Internet Protocol stack. This paper presents NEAT, a user-space library that can provide an alternate transport API. NEAT allows applications to request the service they need using a new design that is agnostic to the specific choice of transport protocol underneath. This not only allows applications to take advantage of common protocol machinery, but also eases introduction of new network mechanisms and transport protocols. The paper describes the components of the NEAT library and illustrates the important benefits that can be gained from this new approach. NEAT is a software platform for developing advanced network applications that was designed in accordance with the standardization efforts on Transport Services (TAPS) in the Internet Engineering Task Force (IETF), but its features exceed the envisioned functionality of a TAPS system. 
  •  
7.
  • 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
  •  
8.
  • Santos, Ricardo, 1990-, et al. (författare)
  • A NEAT framework for application-awareness in SDN environments
  • 2017
  • Ingår i: 2017 IFIP Networking Conference (IFIP Networking) and Workshops. - : IEEE. - 9783901882944
  • Konferensbidrag (refereegranskat)abstract
    • Software-Defined Networking (SDN) has led to a paradigm shift in the way how networks are managed and operated. In SDN environments the data plane forwarding rules are managed by logically centralized controllers operating on global view of the network. Today, SDN controllers typically posses little insight about the requirements of the applications executed on the end-hosts. Consequently, they rely on heuristics to implement traffic engineering or QoS support. In this work, we propose a framework for application-awareness in SDN environments where the end-hosts provide a generic interface for the SDN controllers to interact with. As a result, SDN controllers may enhance the end-host’s view of the attached network and deploy policies into the edge of the network. Further, controllers may obtain information about the specific requirements of the deployed applications. Our demonstration extends the OpenDaylight SDN controller to enable it to interact with end-hosts running a novel networking stack called NEAT. We demonstrate a scenario in which the controller distributes policies and path information to manage bulk and low-latency flows. 
  •  
Skapa referenser, mejla, bekava och länka
  • Resultat 1-8 av 8

Kungliga biblioteket hanterar dina personuppgifter i enlighet med EU:s dataskyddsförordning (2018), GDPR. Läs mer om hur det funkar här.
Så här hanterar KB dina uppgifter vid användning av denna tjänst.

 
pil uppåt Stäng

Kopiera och spara länken för att återkomma till aktuell vy