The POINT project aims to develop a solution that will offer IP-based services over an operator network that is entirely based on the principles of Information-Centric Networking (ICN). The ultimate goal of POINT is to provide IP-based services with improved (quantitative and qualitative) performance compared to contemporary IP networks. For this, POINT brings together past research on ICN architecture and implementations with a realistic deployment path aimed at individual ISPs who desire to reap the benefits of ICN, without overhauling their entire service offering or forcing their clients to modify or replace their devices and software.
Such benefits will include, among others, referring to content by name rather than by provider address, thus allowing content to be fetched from multiple (surrogate) servers and caches; support for native ICN-based multicast in the network, thus allowing considerable savings for the synchronous or quasi-synchronous delivery of popular content; securing the content rather than the endpoint, thus allowing users to directly control access to their data; and centralized control over routing, thus allowing operators to apply traffic engineering rules. POINT will realize this proposition through an ICN prototype, which will incorporate both a complete network protocol stack and a set of helper libraries and services, integrated into the SDN-enabled infrastructure of an ISP.
This POINT proposition is differentiated in two key aspects from past ICN research. Firstly, we aim to complement the core network of a single ISP transparently to both its customers and its providers or peers. Secondly, we declare the current IP-based Internet as our major use case (while still allowing for transitioning to native ICN services over the long term), piggybacking on the innovation that the current Internet already provides, in order to accelerate the adoption of ICN in real operator deployments. We do not propose replacing the entire Internet.
Both aspects mandate that existing User Equipment (UE) should not be modified at all, with the possible exception of downloadable scripts and configuration files, such as proxy settings. This allows the ISP to amend, or even replace, its core network, without any co-ordination with third parties, while continuing to serve its current customer base without any changes to current equipment or applications on the customer’s side. It will, of course, be possible for emerging equipment, such as novel Internet of Things (IoT) devices, to take advantage of the advanced capabilities offered by the ICN core network.
With this in mind, we postulate a gateway-based approach, in order to preserve the IP interfaces towards the User Equipment (UE) and IP applications and services in general. In this approach, the bridging between IP and ICN is performed at the Network Attachment Points (NAPs), i.e., the access gateways from ISP customers to the network, and the ICN border gateway (ICN BGW), i.e., the access from and to the general Internet. Furthermore, the POINT platform will take advantage of the current ISP migration to Software Defined Networking (SDN) equipment, piggybacking on the success of SDN in bringing about software-controlled, flow-managed, networks, by directly integrating with such emerging equipment at the architecture, as well as the platform level. With this approach, the ISP should be able to reap the benefits from the underlying ICN core by offering ‘better’ IP services, where ‘better’ can mean improved user experience, more privacy and security, increased ISP capacity, flexibility, increased utilization and enhanced network operation, or lower capital and operating costs.
To ensure that the development of the POINT platform stays in focus, we need to ensure that it is driven by these user-side or ISP-side improvements. Therefore, are developing a set of scenarios that will showcase areas where the POINT approach will be able to improve upon existing IP networks, by taking advantage of the unique features of the POINT platform. These scenarios will then lead to a set of high-level requirements that the POINT prototype should satisfy in order to achieve its goals. Those requirements that cannot be assessed in a Yes/No manner, will be further translated into a number of verifiable Key Performance Indicators (KPIs) which will be used to verify whether the POINT prototype has achieved its goals. Finally, a detailed (initial) architecture for the POINT platform and a set of specifications for it will be derived from the KPIs, taking into account past research on ICN and incorporating existing software wherever possible.
Test-beds and Evaluation
Our key objective is to critically evaluate our hypothesis that running IP-over-ICN results in a ‘better’ networking experience for the major stakeholders, compared to the present-day TCP/IP networking with classical routing and switching. Our evaluation work has two distinct aspects to it, validation and quantitative evaluation.
Validation consists of verifying that the entire system satisfies all the functional requirements imposed on it. These include the capability of end users to employ unmodified UEs to access the various services, many of the requirements on improved privacy and security, and so on. In addition to local deployments, many of these will be validated using our extensive overlay test-bed infrastructure. This test-bed is constructed using VPN connections between 10 different sites, each equipped with several physical and virtual machines on which our platform can be deployed. This overlay test-bed will play a major role in our development efforts, facilitating rapid integration and prototyping for the platform engineering work.
Quantitative Evaluation, takes a different approach, measuring the performance of our system against a carefully selected collection of KPIs measuring both end user quality of experience, as well as different performance aspects of interest to the network operator, all for diverse applications. Examples of the former include raw network performance measures such as throughput, latency, and jitter, but also more perceptual measures such as time to render for interactive browsing. For the latter group of KPIs, we will include aggregate performance metrics such as overall network capacity and percentage of signalling overhead, but also techno-economic aspects such as estimates of the network cost, predictability of traffic loads, and traffic engineering efforts needed. In order to obtain high quality data on these KPIs, a dedicated test-bed infrastructure is needed, the performance of which is not influenced in an uncontrolled manner by the usage of the underlying network, as is the case for our overlay test-bed.
For these reasons, the quantitative evaluation phase is planned to be conducted by deploying and running test trials of the system in an actual production network of a network operator aiming towards large scale validation involving real users. This diagram shows how the R&D testbed facilities at PrimeTel PLC are connecting the real network through an IP backbone, from where it could also connect to other servers of interest, e.g. for IPTV, VoD, Content Services etc. The R&D testbed has a number of servers for test purposes co-located at one of the company’s main datacentres, offering numerous connectivity options through typical routers, switches and other typical network equipment. Moreover, R&D engineers will, together with external users, act as beta-testers to access the R&D testbed facilities via a number of different platforms. To make the trial multi-domain, PrimeTel may further connect to the overlay testbed through L3 connectivity to better illustrate IP-over-ICN use case scenarios of interest, such as ones related to unicast streaming, multipath streaming etc. In such an integrated test-bed both, content servers or content headless clients, could be used at various remote locations at the domains of other test-bed partners for further testing.