Feasibility of IP-over-ICN - Aalto

This is an electronic reprint of the original article.This reprint may differ from the original in pagination and typographic detail.

Powered by TCPDF (www.tcpdf.org)

This material is protected by copyright and other intellectual property rights, and duplication or sale of all or part of any of the repository collections is not permitted, except that material may be duplicated by you for your research use or educational purposes in electronic or print form. You must obtain permission for any other use. Electronic or print copies may not be offered, whether for sale or otherwise to anyone who is not an authorised user.

Benseny, Jaume; Lagutin, Dmitrij; Hämmäinen, Heikki; Trossen, DirkFeasibility of IP-over-ICN

Published in:Telecommunication Systems

DOI:10.1007/s11235-019-00593-5

Published: 01/01/2020

Document VersionPublisher's PDF, also known as Version of record

Published under the following license:CC BY

Please cite the original version:Benseny, J., Lagutin, D., Hämmäinen, H., & Trossen, D. (2020). Feasibility of IP-over-ICN. TelecommunicationSystems, 73, 27–46. https://doi.org/10.1007/s11235-019-00593-5

https://doi.org/10.1007/s11235-019-00593-5

https://doi.org/10.1007/s11235-019-00593-5

Telecommunication Systems (2020) 73:27–46https://doi.org/10.1007/s11235-019-00593-5

Feasibility of IP-over-ICN

Jaume Benseny1 · Dmitrij Lagutin1 · Heikki Hämmäinen1 · Dirk Trossen2

Published online: 31 July 2019© The Author(s) 2019

AbstractThe IP-over-ICN strategy intends to establish islands of networks that internally route packets based on Information-CentricNetworking (ICN)while maintaining IP-based protocols at the ingress and egress of the network. This strategy aims at benefitsfrom the use of ICN-based routing while maintaining backward compatibility with IP-based services. In the long run, an ICN-based Internet architecture may emerge from the interconnection of these ICN-based islands. We assess the feasibility of thisstrategy by discussing the willingness of Internet stakeholders to adopt one particular IP-over-ICN implementation basedon the Publish-Subscribe Internet Technologies (PURSUIT) for flow-based routing, multicast routing, and service routing.We suggest that the IP-over-PURSUIT solution offers viable mechanisms for IP interoperability and routing scalability aswell as potential advantages in comparison to substitutes, including IP-based solutions, such as IPv6; Multiprotocol LevelSwitching; and hybrid ICN; as well as other IP-over-ICN implementations based on Content-Centric Networking.We indicatethat triple play operators and micro-operators have a greater incentive to adopt IP-over-PURSUIT since they can maximizethe utilization of the multicast and service routing, respectively. However, we argue that IP-over-PURSUIT requires newexterior inter-stakeholder interfaces for significant operator traffic to be delivered through its new and cost-efficient routingcapabilities, thus increasing the likelihood of operator adoption. Finally, we suggest that the advent of an ICN-based Internetarchitecture might be delayed until Internet stakeholders can trustworthily delegate the delivery of valuable content andservices via information-based exchange points.

Keywords IP-over-ICN · PURSUIT · Internet architecture · Interior gateway protocol · Feasibility

1 Introduction

The Internet Protocol (IP) was designed in the 70s, imple-menting a host-centric communication model. As Inter-net usage has shifted towards information retrieval, alter-native Internet architectures have been proposed imple-

This work was supported by the EC H2020 RIFE Project Grant No.644663 and by the EC H2020 POINT Project Grant No. 643990.

B Jaume [email protected]

Dmitrij [email protected]

Heikki Hämmä[email protected]

Dirk [email protected]

1 Communications and Networking Department, AaltoUniversity, Konemiehentie 2, Espoo, Finland

2 InterDigital Europe, 64 Great Eastern St, London, UK

menting data-centric models, including Data-Oriented Net-workArchitecture (DONA) [1],Content-CentricNetworking(CCN) [2], The Publish Subscribe Internet Technology(PURSUIT) [3], and Network of Information (NetInf) [4].However, these architectures have not been deployed sincethey require the globally synchronized substitution of IPand endanger the market position of dominant stakeholders[5–8].

The feasibility of Internet architectures implementingInformation-Centric Networking (ICN) has been analyzedby anticipating stakeholder conflicts or tussles [8]. Tussleanalyses have identified conflicts based on trust, economics,security, among others.More importantly, key design aspectsremain unanswered, including the management of globalcontent identifiers or the inter-domain routing of multi-source content [9–11]. To address these challenges, twodeployment strategies have been devised aiming for grad-ual ICN deployments that remain IP interoperable, namelyICN-over-IP and IP-over-ICN [12].

123

http://crossmark.crossref.org/dialog/?doi=10.1007/s11235-019-00593-5&domain=pdf

http://orcid.org/0000-0002-4063-7255

28 J. Benseny et al.

Although the ICN-over-IP strategy enables rapid deploy-ment of ICN islands, these islands have IP/ICN overlappingrouting functions, which may increase operator costs andavoid protocol competition.1 In contrast, the IP-over-ICNstrategy deploys native ICN networks that remain interoper-able with existing IP networks/devices via gateways. Withinthe ICN network, data-centric routing features, such as mul-ticast delivery; mobility support; fast indirection; in-networkcomputing, can be exploited to handle IP-based protocols[12]. Thus, IP-over-ICN enables operators to increase theefficiency of the underlying transport network while keepingsynergies with the IP ecosystem.

This article evaluates the feasibility of IP-over-ICNemploying a conceptual framework created to analyze Inter-net protocols that emerge fromconsensus-based forums, suchas the Internet Engineering Task Force (IETF) [15].We studystakeholder adoption by (1) analyzing the IP-over-PURSUITarchitecture,2 (2) comparing stakeholder-specific benefitsacross alternative value networks, and (3) comparing its tech-nical implementation against substitute solutions, includingIP-over-CCN, IPv6,Multiprotocol Level Switching (MPLS),and hybrid-ICN (hICN). The study includes three use casesof significant economic attractiveness, including flow-basedrouting, multicast routing, and service routing. We addresstechnical and business feasibility challenges by conduct-ing new technical evaluations, referring to simulation resultsfrom key publications, suggesting design modifications, andproviding evidence from a field trial. Finally, we specificallydiscuss operator adoption depending on service offering,market conditions, and stakeholder collaboration.

The rest of this article is structured as follows. Section 2describes the architecture and functions forming the IP-over-PURSUIT routing solution. Section 3presents the frameworkfor the feasibility analysis of Internet protocols and reportsfeasibility results for IP-over-PURSUIT as an IGP solution.Section 4 discusses the feasibility of the IP-over-ICN deploy-ment strategy. Finally, Sect. 5 summarizes conclusions.

2 Background on the IP-over-PURSUITrouting solution

2.1 PURSUIT ICN network

In contrast to the destination-based routing of IP, the PUR-SUIT ICN network implements path-based routing through

1 Recently, the Hybrid Information-Centric Networking (hICN) hasbeen proposed, inserting CCN into IPv6 and reducing function overlap.However, it may require an inconvenientmapping of entire IPv6 addressfamilies to content-named prefixes [13,14].2 We study the IP-over-PURSUIT architecture because it provideswider IP interoperability than IP-over-CCN, allowing the simultaneoustranslation of IP multicast, HTTP, CoAP, and general IP into PURSUIT.

three ICN functions developed in the FP7 PURSUIT project[3,17]. The rendezvous function (RV) manages the names-pace of the information items being published and subscribedto, allowing for matching demand and supply for infor-mation. The topology manager function (TM) constructssuitable forwarding identifiers (FIDs) connecting sourcesand sinks of information. Ultimately, the forwarding func-tion (FWD) delivers the information according to the matchperformed by theRV following the delivery path indicated bythe FID. One efficient implementation of the FWD utilizespath-based rather than flow-based forwarding. For this, theTM labels every link in the network with a specific bit posi-tion in a bit-field, similarly to previous Bloom-filter-basedapproaches [18]. For this, each link within the network isidentified by a constant length link identifier (LID). Thus,FIDs are computed by the TM by executing a binary ORoperation over the LIDs along the delivery path between thematched publishers and subscribers. TheFID is then includedin the packet header. Switches along the path will performa binary AND operation between the FID and the LID foreach of the switch’s output ports. Thus, forwarding decisionsare based on bit-field matching. A positive match means thatthe FID contains the specific LID, in which case the packetis sent to that port. Multiple matches between the LID andoutput ports can occur at once, in which case the packet isforwarded to multiple ports, enabling multicast. In this work,we assume that positions in the bit-field are not used for morethan one link, preventing false positives.

At the deployment level, the RV and the TM functionsmight be located in central locations within the network,while the forwarding must be present in all intermediaryswitches. One significant advantage of the path-based for-warding via bit-field matching is the ability to create anydelivery paths, including point-to-multipoint (P2MP) multi-cast while keeping the required state at the switches constant[19]. Such delivery paths can also be created in an ad-hocmanner by combining existing point-to-point (P2P) pathsinto a new P2MP path through a binary OR combination ofthe original ones. However, the number of identifiable linkswithin a network is limited by the FID length (e.g., four-bitidentifiers can only store four non-overlapping link names)[20].

2.2 IP-over-PURSUIT architecture

The IP-over-PURSUIT solution follows a gateway-basedarchitecture in which an interior ICN network is borderedby Network Attachment Points (NAPs), as shown in Fig. 1.Thus, NAPs act as IP gateways, translating IP-based proto-cols into ICN traffic, and vice versa.More importantly, NAPsare purposefully designed to execute multiple applicationseach of which handles a specific IP-based protocol. Theseapplications, known as protocol handlers, can optimize the

123

Feasibility of IP-over-ICN 29

IPNAP

IP

IP

IP

IP

IP-onlyUE

IP

NAP

IP-only UE

IP-only UE

RV

SDN Switch

SDN Switch

TM

NAP

NAP

SDN Controller

IP (BGP)

Fig. 1 IP-over-PURSUIT gateway-based architecture [16]

transmission of IP data taking advantage of the ICN func-tions, including multicast, caching, and fast indirection ofhigher layer protocols [16,21].

At the forwarding level, standard SDN switches are usedto convey the traffic. Since SDN switches support forward-ing based on IPv6 addresses, the size of FIDs is exactly thesame as the combined size of the IPv6 source and desti-nation addresses (256 bits), FIDs can be embedded in thepacket header instead of the IPv6 addresses for forwardingdecisions. At the same time, the node LIDs are stored inflow-tables of SDN switches. Support for forwarding basedon bit-field matching (Arbitrary Bit Match, ABM) has beenadded to the OpenFlow 1.3 release [16,19]. Therefore, anyOpenFlow 1.3 compatible SDN equipment can be used withthe IP-over-PURSUIT solution.

2.3 IP interoperability

The IP-over-PURSUIT solution is IP interoperable thanks tothe interplay between the IP handler running in NAPs, andthe IP namespace stored in the RV. This namespace orga-nizes the IP address space according to address prefixes, asshown in Fig. 2. Thus, when an IP packet arrives at an ingressNAP, either a publication or a subscription is added to thescope with the longest prefix-match based on the packet IPdestination. In the case of an IP packet traveling from Ato B, the A-facing NAP publishes the packet to the addressprefix of B in behalf of A. Upon receiving this publication,the RV function matches it with a previous subscription ofthe B-facing NAP to the address prefix of B. Then, the RV

root identifier

I1

IP addresses outside ICN networkIP addresses inside ICN network

… …

IP addresses according to prefix I1

I2 IM 01 02 0M

Fig. 2 IP namespace [22]

triggers the A-facing NAP to send the packet to B throughthe B-facing NAP. For this, the A-facing NAP looks up itslocal database for the appropriate FID to reach the B-facingNAP. The first packet sent between A and B includes animplicit subscription to the prefix address of A in behalf ofB, thus ensuring that the B-facing NAP immediately sendsresponses produced by B back to the A-facing NAP, with-out consulting the RV. Since IP gateways keep a partial copyof the IP namespace, the RV is not consulted for each pathrequest. This procedure is only required for the first datapacket exchange between two IP endpoints. Subsequent datapackets can be sent using the allocated FIDs. To facilitateforwarding inwards and outwards the ICN network, the pre-fixes are split into user-facing NAPs (Ii), and Internet-facingNAPs (Oi), respectively.An additional namespace is requiredto support subnet-based addressing, enabling NAPs to sub-scribe to entire subnets [16].

123


2.4 Handling specific IP-based protocols

The IP-over-PURSUIT solution currently provides protocolhandlers for IP multicast, HTTP, and CoAP. These handlersoptimize the transmission of IP data in the ICN network bytaking advantage of the ICN functions, including multicast,caching, and fast indirection of higher layer protocols. In thissection, we describe how these protocols utilize ICN-basedoperations and namespaces to handle IPmulticast and HTTP.

For IP multicast, NAPs execute the IGMP handlerenabling the addition of and subscription to IP multicastaddresses in the IGMP namespace. In addition, NAPs alsoexecute the IP multicast handler to compute P2MP deliv-ery paths with as many destinations as client-facing NAPsbelong to the multicast group. This computation, known asad-hoc multipath creation, can be autonomously executedby the server-facing NAP by applying a logical OR opera-tion over the individual P2P FIDs. When the data is finallyreceived at the client-facing NAPs, they generate as many IPmulticast packets as served IP clients [16].

For HTTP, the HTTP handler in client-facing NAPscan aggregate quasi-synchronous HTTP requests, which aredirected to the same Uniform Resource Locator (URL) butoriginated from different local IP clients, into a single HTTPrequest that is transported over the ICN network. In turn,the resulting HTTP response is delivered back to the client-facing NAPs via a P2MP delivery path. This P2MP path isagain created by the server-facing NAP via ad-hoc multi-path creation, i.e., the binary OR of the incoming requestpath information. Finally, the client-facing NAPs generatesas many individual unicast HTTP responses as requesting IPclients. We refer to this functionality as the HTTP coinciden-tal multicast. For this functionality to work, HTTP handlersregister the relevant Fully Qualified Domain Name (FQDN)of a service in the HTTP namespace by assigning ContentIdentifiers (CID), as shown in Fig. 3. Reverse-CIDs (rCIDs)are also created for client-facing NAPs to generate HTTPresponses that follow the original unicast semantic. For this,rCIDs include not only the URL but other HTTP requestsparameters [22].

The performance of HTTP-based services can be furtherimproved through the notion of surrogate services. These ser-vices are IP-level endpoints exposing FQDNs that are alreadyregistered in the local NAP, resulting in several subscrip-tions to the same CID. Thus, for a given request, the RV canchoose between one or more service endpoints which will beincluded in the final path computation by the TM. Further-more, this path computation can be constrained by policies,including FQDN-based policies and delay-based policies. Inthe latter case, theTMwould need to realizemonitoring capa-bilities to weigh the path computation algorithm with delayconstraints.

I O

CIDrCID

hash(FQDN) hash(URL) hash(FQDN) hash(URL)

Fig. 3 HTTP namespace [22]

2.5 Mobility management and service indirection

The gateway-based architecture of IP-over-PURSUIT facil-itates both the handover of User Equipment (UE) betweenNAPs and the switchover of HTTP connections between sur-rogate services.

When a UE detects a NAP providing a better signal recep-tion than the NAP to which it is currently attached, it startsa handover from the old NAP to the new NAP. First, the oldNAP directly informs of the de-attachment to all other NAPswhich had established packet exchange with the UE, i.e., itdirectly requests the un-subscription to the address prefix ofthe UE. After the UE is physically attached to the new NAP,the new NAP publishes incoming packets to the RV accord-ing to the address prefix of their IP destination. At this point,the RV re-matches the previously existing publications andsubscriptions for the UE, thus triggering the new NAP tore-establish communications. On the other end of the packetexchange, other NAPs realize there is a new NAP acting asthe IP gateway for theUE since the newNAP always includesan implicit subscription within the first packet after an RVupdate. Note that FIDs do not need to be re-calculated bythe TM, IP gateways only need to switch the old FID by thenew one, which is either provided by the RV or looked upfrom a local copy of the IP namespace. As a pre-condition formobility, NAPs need to execute theDHCP handler assigningthe same IP address to UE when they re-attach during a han-dover. For this, the unequivocal assignment of IP addressesto UE is centrally stored in the DHCP namespace of the RV.Summarizing, in IP-over-PURSUIT, handovers are based onthe substitution of NAPs as publishers and/or subscribersfor the IP addresses of UE thanks to the decoupling of IPaddresses from the UE location. More sophisticated han-dover procedures have been specified for IP-over-PURSUITestablishing delivery paths withmultiple destinations, simul-taneously reaching those NAPs with the highest probabilityof re-attachment. For this, a handover handler and namespaceare required [16,23].

123


As mentioned in the previous section, surrogate servicesenable the RV to select the most suitable source of contentfor HTTP requests. Therefore, they allow for the dynamicswitchover from one HTTP surrogate service instance toanother. For this, the TM invalidates forwarding informa-tion upon new registrations or failover indications, leadingto a new path computation at the next service request atthose NAPs that serve initiating clients.We refer to this func-tionality as HTTP service indirection [24]. Hence, IP-over-PURSUIT can sequentially execute a handover followed bythe switchover of HTTP connections, thus connecting the re-attachedUE to the surrogate server that offers the best servicequality [23]. The switchover is even possible during sessionruntime since details on individual HTTP requests are cen-trally stored in the HTTP namespace. For this, the RV needsto update state information across namespaces, given that thehandover and switchover based on the IP namespace and theHTTP namespace, respectively. In case no viable surrogateserver exists after a handover (or after a new attachment), theavailability of emerging surrogate services can be directlynotified to client-facing NAPs. Although the service indi-rection functionality works for stateless HTTP applications,surrogate services need to synchronize state information forapplications with user context. Application-level synchro-nization is out of the scope of this study.

2.6 Routing scalability

The routing scalability of the IP-over-PURSUIT solution islimited by the scalability of its network functions. For scalingthe FWD, the IP-over-PURSUIT solution adopts a zoningmechanism that divides the ICN network into zones with amaximum number of links [20]. Due to the integration withSDN switches, the FID length is constrained by the size ofthe IPv6 header, thus limiting the number of links that canbe included in a FID. In this work, we assume that positionsin the FID are only used to identify one link per zone, thuspreventing false positives. The proposed zoning mechanismrequires the IPv6 packet header to include not only a zone-specific FID but also a zone identifier (ZID). In addition, thepacket payload piggybacks FIDs of future traversed zones.Therefore, inter-zone routers are also required in the IP-over-PURSUIT architecture to update the packet header with thecorrect (ZID+zone-specific FID) according to the next zonethe packet is forwarded to.

For scaling the RV and TM, virtual instances of thesefunctions are replicated throughout the network using Net-work Function Virtualization (NFV). Thus, the workloadgenerated by NAPs is adequately balanced between RV/TMreplicas. Hereafter, we refer to this scalability mechanism asthe NFV-based RV/TM. The state information in RV/TMreplicas can be updated through a distributed databasemechanism. For the RV, the state information includes the

namespaces, the active subscriptions, and the publications(the latter are only used in reading mode). For the TM, thisinformation includes the state of links which is only updatedafter an inventory change, i.e., when a forwarding node entersor leaves the topology. Regarding the workload generated byNAPs, path computation requests only occur for initial ser-vice requests, i.e., only the first time that a specific URL isbeing requested at the client-facing NAP. If any other futurerequest is issued at the same NAP (from any of its locallyattached clients), no path computation request is needed andtherefore neither RV nor TM is used. Server-facing NAPs donot generate any load on the RV/TM since the return pathfor packet equals that of the forward path, unless weightedpolicies are used that differentiate forward from return paths.

3 Feasibility analysis

3.1 Framework for the feasibility analysis of Internetprotocols

This article employs a conceptual framework created toanalyze the feasibility of new Internet protocols that aredeveloped in consensus-based forums, such as the IETF[15]. The framework helps to identify the most attractiveuse cases, to compare the protocol implementation againstits substitutes, and to assess the incentives of stakeholdersto participate in its deployment. The framework establishesa sequential and iterative process, as shown in Fig. 4. Eachstep in the process contains clearly defined objectives whichare listed in Table 1.

The framework has been used to analyze protocols witha moderate level of uncertainty regarding their adoption bystakeholders. For example, it has been used on CoAP [25] ,Multipath-TCP [9], and Host Identity Protocol [26].

3.2 Use case analysis

We identify three use cases in which Internet stakeholderscan obtain significant benefits from the IP-over-PURSUITsolution.

The Multiprotocol Label Switching (MPLS) has beenwidely adopted by operators to implement traffic engineer-ing and VPNmanagement via Label Switched Paths (LSPs).Recently, flow-based solutions have been developed enabledby IPv6 and SDN to provide similar routing features, albeitwith their specific challenges in terms of scalability andcosts [27]. Given the significant market opportunity derivedfrom MPLS phase out, we decide to study the ability ofIP-over-PURSUIT to perform flow-based routing and traf-fic engineering through path-based routing and associatedbenefits regarding SDN integration.

123


Fig. 4 Framework for the feasibility analysis of Internet protocols [15]

Table 1 Steps in the feasibility analysis

Analysis steps Objective

1 Use case analysis To identify use cases in which the IP-over-PURSUIT solution can providepotential benefits to Internet stakeholders

2 Technical architecture To identify the architecture elements that serve the use case needs

To identify deployment actions for the identified architecture elements

3 Value network analysis To identify the relevant stakeholders for the use case

To assign deployment actions and business roles to stakeholders

To identify alternative value networks for the use case

4 Deployment environmental analysis To compare the protocol implementation against substitute solutions andidentify advantages and drawbacks for each use case

To identify external factors affecting the feasibility of the protocol

5 Feasibility analysis To identify and evaluate the key technical and business factors that candispute the potential benefits of IP-over-PURSUIT

6 Solution analysis To identify positive net benefits for all relevant stakeholders as well assignificant deployment challenges of the protocol for each use case

The IP multicast protocol has been deployed by opera-tors offering linear TV services. However, consumer surveysreport consistent media consumption growth through OverThe Top (OTT) services including Video-on-Demand (VoD).For instance, the US market is experiencing cable-to-VoDsubstitution driven by lower prices of VoD services whichreached 50% market penetration in 2016 [28,29]. Given thatOTT services are provided by Content Delivery Networks(CDNs) via best-effort IP, IPTV operators are not able toexploit the IPTV infrastructure nor differentiate from con-nectivity oriented operators, thus losing content-related rev-enues. As a reaction, European operators following a serviceconvergence strategy are acquiring media assets.3 Hence, wedecide to study the ability of the IP-over-PURSUIT solution

3 The Swedish operator Telia bought the Bonnier Broadcasting com-pany, thus taking control over 3 linear TV channels [30]. The same

to implement scalable IP multicast and improve the dis-tribution of HTTP-transported media content via multicastrouting.

Newmobile edge services with low-latency requirements,such as vehicle-to-network services, are expected to emergedriven by cost-efficiency gains [31]. To this end, server-sideapplication logic and data need to move closer to end usersand follow themacross distributed computing resources (e.g.,across an edge cloud infrastructure). In this context, futurerouting solutions are expected to support the deployment ofvirtual service instances on the edge of the network and seam-

Footnote 3 continuedoperator also acquired distribution rights over the Finnish ice hockeyleague. Similarly, the Spanish operator Telefonica acquired rights overthe UEFA Champions League and UEFA Europa League for its resi-dential market.

123


Table 2 Identified use cases

Use cases Purpose

Flow-based routing To evaluate the ability of IP-over-PURSUIT to perform flow-basedrouting employing its path-basedrouting functionality

Multicast routing To evaluate the improved imple-mentation of IP multicast andthe improved delivery of HTTP-transported media via HTTP coin-cidental multicast

Service routing To evaluate the ability of IP-over-PURSUIT to enable mobile edgeservices viaUEhandover andHTTPservice indirection

lessly switch connections between instances. Therefore, wedecide to study the ability of the IP-over-PURSUIT solutionto enable mobile edge services via service routing, given itsability to handover UE between NAPs and reroute servicesvia HTTP service indirection.

Results from the use case analysis are summarized inTable 2.

3.3 Technical architecture analysis

IP-over-PURSUIT can serve the needs of the three use casesby adopting different architecture configurations, as shown inTable 3. In each configuration, the ICN functions provide dif-ferent functionalities. For example, as the routing complexityof use cases increases, NAPs need to gradually execute addi-tional protocol handlers.

3.3.1 FWD function

The current IP-over-PURSUIT design keeps a minimal statein routers and requires low controller-to-switch SDN inter-action. A key feature of the IP-over-PURSUIT architecture

is that the FWD remains as a bit-field matching operationacross use cases. Therefore, flow-tables in SDN switchesonly need to account for the switch own links, keeping thestate at its minimum and independent from traffic demand.Furthermore, flow rules can be inserted proactively by SDNcontrollers during the network bootstrapping, removing flowsetup latency caused by reactive flow insertion. As a result,controller-to-switch interaction is very low since link-state-updates are only required when the topology changes.

The current IP-over-PURSUIT design states that a zoningmechanism is required to ensure FWD scalability. However,no guidelines exist on how zones should be created, i.e.,providing a maximum number of links per zone. Therefore,the zone-based routing scalability mechanism remains as anopen feasibility challenge.Moreover, inter-zone routers needto store network state mapping links to zones, thus breakingthe IP-over-PURSUIT promise of stateless routing.

3.3.2 RV/TM functions

The NFV-based RV/TM guarantees that the RV and the TMact as a logically centralized function, while their executioncan be distributed, as described in Sect. 2.6. From the TM’sviewpoint, link-state information needs to be logically cen-tralizedmaintaining a network-wide scope, thus enabling thecomputation of FIDs connecting the opposite extremes of thenetwork. From the RV’s viewpoint, the logically centralizedmanagement of server-side subscriptions is also necessary toguarantee network-wide content availability. Based on theseobservations, the current design of the NFV-enabled RV/TMresembles a distributed flat SDN control plane that addi-tionally manages pub/sub information and resolves contentrequests through the user plane [27]. Although the centraliza-tion of link-state and pub/sub information can significantlysimplify network management, it also creates a single pointof failure if the network function replication is not conductedcorrectly.

Table 3 Architecture configurations for the use cases

Use cases In NAPs In the RV In the TM In the FWD

Flow-based routing(Architecture config. 1)

IP handler IP namespace Link-state data Bit-field matchPath computation

Multicast routing(Architecture config. 2)

IP handler IP namespace Link-state data Bit-field matchIGMP handler IGMP namespace Path computation

IP multicast handler HTTP namespace

HTTP handler

Service routing(Architecture config. 3)

IP handler IP namespace Link-state data Bit-field matchHTTP handler HTTP namespace Path computation

DHCP handler DHCP namespace Monitor FQDN

Handover handler Handover namespace connections

123


Although the current IP-over-PURSUIT design estab-lishes that the workload generated by NAPs is adequatelybalanced amongRV/TM replicas, no guidelines exist indicat-ing how zones should be created, i.e., providing a maximumnumber of NAPs or aggregated active subscriptions perreplica.

3.3.3 Function deployment

Since the majority of elements in the IP-over-PURSUITarchitecture are software-based, they can be replicated anddeployed on the strategically located equipment in thenetwork. While RV/TM replicas, SDN controllers, and inter-zone routers can be deployed in central locations; NAPsshould be deployed on the network edge. The deploymentof IP-over-PURSUIT can be facilitated by Infrastructure asa Service (IaaS) solutions, given that virtual resources canbe dynamically assigned to network functions. IaaS solu-tions can also facilitate the deployment of third-party servicesin the network, i.e., HTTP surrogate services. In this con-text, IP-over-PURSUIT can be deployed either following thetraditional IGP approach, i.e., as a single network routingsolution, or it can also be deployed in a part of the network.

3.4 Value network analysis

We assess the willingness of Internet stakeholders to adoptIP-over-PURSUIT by comparing alternative value networks,aiming to identify those networks that better balance benefitsamong stakeholders [32,33]. We generate value networks byassigning architectural elements and related business roles tostakeholders. Finally, actor-specific benefits are derived frominterfaces and contracts that connect technical elements andbusiness actors, respectively.

Use case 1: flow-based routing Operators that provide IPconnectivity services can deploy IP-over-PURSUIT as anIGP solution to perform flow-based routing and, they cankeep control over all elements in the architecture. In otherwords, operators do not need to concede the control of anyarchitectural element to stakeholders. Therefore, operatorsdo not need to expose any additional technical interface apartfrom the existing inter-domain interfaces, which remain IPinteroperable. Hence, connectivity operators can adopt IP-over-PURSUIT in its architecture configuration 1 withoutchanging current value networks for the provision of IP con-nectivity services.

Use case 2: multicast routing Connectivity operators thatalso provide content-based services, e.g., triple play opera-tors, can also deploy the IP-over-PURSUIT solution as anIGP and keep control over all architectural elements. How-ever, the use case benefits obtained by the operator, i.e., therelease of link capacity due to multicast, depend on the frac-

tion of traffic that can be delivered via IPmulticast andHTTPcoincidental multicast. In both cases, operators need to signbusiness contracts with content owners to deliver a substan-tial amount of traffic through these protocols. Note that themulticast of content that is not protected by copyright mightnot release enough capacity to justify adoption.

Triple play operators (and IPTV operators) already per-form contract-based content provision via the IP multicastprotocol. Further, they have complete control over the deliv-ery process since they typically manage both the contentservers and the network. As a result, they can enjoy froman improved implementation of IP multicast without anyadditional inter-stakeholder technical interface or businesscontract.

However, triple play operators do not control the provisionof OTT content, i.e., they distribute OTT content as any otherHTTPS communication because of the payload encryption.To address this technical issue, business contracts should besigned to allow the exchange of certificates, enabling oper-ators to publish OTT content on the RV.4 However, OTTsmay lack incentives to sign these contracts since their contentis already delivered successfully by CDNs and they do notobtain an immediate benefit from IP-over-PURSUIT. Moreprecisely, the release of operator link capacity via HTTPcoincidental multicast does not benefit OTTs. Moreover, thecurrent IP-over-PURSUIT design does not yet provide toOTTs the same level of information on consumer receivedquality or consumer behaviour in comparison to existingCDN solutions. In the worst case scenario, some implemen-tations could deliberately prevent OTTs from obtaining thisinformation. Since in HTTP coincidental multicast quasi-synchronous HTTP requests are combined into one singlerequest, the number of requesting users could be hidden fromcontent servers, limiting personalized advertisements, etc.Hence, for operators to fully enjoy the benefits of HTTPcoincidental multicast, new inter-stakeholder technical andbusiness interfaces are required for certificate exchange andconsumer information sharing, at least.

Use case 3: service routing use case Although mobile edgeservices do not yet exist, we generate plausible value net-works by adapting business roles and stakeholders that existin the provision of cloud services.We envision that value net-works for the provision of mobile edge services will includea business role responsible for the provision of surrogate ser-vices and, they will also include a stakeholder that providesedge applications.

Operators providing mobility services could deploy IP-over-PURSUIT as an IGP, albeit they could only providemobility via Wi-Fi, given that a pure IP-over-PURSUIT sys-tem is not currently able to attach UE via 3GPP protocols.

4 Technically, certificates are needed to generate rCIDs and store themin the HTTP namespace.

123


Table 4 Value network analysis results

Use cases Leading actor(deployment type)

Requiredstakeholders

Disputedbusiness roles

Business contracts(Technical interfaces)

Flow-based routing Connectivity operator (IGP) None None None

Multicast routing Triple play operator (IGP) OTT provider Provision of OTT content Content distributioncontract (RV access)

Service routing Micro-operator (IGP) None None None

MNO (Edge cloud) Edge applicationprovider

Provision of surrogateservices

Service surrogacycontract (RV access)(3GPP signaling)

However, Mobile Network Operators (MNOs) might beinterested in deploying IP-over-PURSUIT on subsystems ofthemobile network.5 MNOscoulddeploy IP-over-PURSUITon the edge cloud since specifications of 5th generationmobile systems (5G) allows local routing and traffic steer-ing [34], thus possibly enabling HTTP service indirectionfor edge applications requiring mobility. However, techni-cal interfaces integrating 3GPP signaling protocols with theRV/TM do not exist yet. Nevertheless, some equipment ven-dors are interested in this integration, as shown in recent IETFdrafts [35].

Although the IGP deployment option might not be attrac-tive to MNOs, it can work for micro-operators serving alimited coverage area, e.g., a campus or a city area. In thismicro-operator-driven value network, the micro-operator islikely to control the provision of surrogate services, giventhat edge application providers have little incentive to servesuch a limited coverage area and, theymost likely are subcon-tracted by themicro-operator [36].As a result, the publicationof surrogate services to the RV is greatly simplified.

When evaluating the assignment of business roles, it is notclear which stakeholder will take control over the provisionof surrogate services. While MNOs can impose their sig-naling protocols within the access network, edge applicationproviders can leverage their pre-existing business relation-ships with end users, forcing some remote control over thesurrogates (i.e., large service providers, such as Google).Therefore, business contracts for service surrogacy need tobe signed between MNOs and edge application providers,thus facing similar challenges than use case 2. We concludethat the adoption of IP-over-PURSUIT to serve the use case 3is more likely in a micro-operator-driven value network thanin an MNO-driven value network.

In summary, although the operator is solely responsiblefor the deployment of IP-over-PURSUIT across all use cases,benefits from multicast and service routing are only realized

5 IP-over-PURSUIT could implement the control plane of 5th genera-tion mobile systems (5G) since surrogate services could implement aservice-based architecture. However, this implementation is limited touser plane routing thus outside the scope of use case 3.

in full when technical interfaces and business contracts areestablished, as summarized in Table 4.

3.5 Deployment environment analysis

The willingness of Internet stakeholders to adopt the IP-over-PURSUIT solution depends on the advantages anddrawbacks provided by this solution in contrast to substitutes.Therefore, we compare the implementation of substitutesolutions against the one of IP-over-PURSUIT for the threeuse cases under study. Substitute solutions include IP-basedsolutions, such as IPv6; MPLS; and hICN as well as otherIP-over-ICN implementations, such as IP-over-CCN.

Since both hICN and IP-over-CCN rely on CCN, webriefly describe this ICN architecture. In a CCN network,users request content items by broadcasting Interest mes-sages containing the name of the content, which followsa hierarchical and aggregate-able structure. In fact, contentnames have a key role in the transport of Interest messagessince CCN routers forward these messages according to aname-based prefixmatch. Similarly to IP forwarding, routersperform a table lookup, matching the content name in pack-ets against the Forward Information Base (FIB), in whichcontent sources (in name format) are associated to one ormore outbound interfaces. For each Interest message that isforwarded, routers update the Pending Interest Table (PIT),thus establishing a reverse path. When Interest messages arefinally received by content sources, content items are sent torequesters encapsulated in Data messages. Along the datapath, routers delete Interest entries from the PIT, enforcingthe principle that one Interest messages retrieves at most oneData packet. This forwarding system has been called softstateful [2].

3.5.1 Advantages and drawbacks compared to IP-basedsolutions

Use case 1: flow-based routing MPLS, IPv6, and, hICNallow flow-based routing. In MPLS, IP packets are assignedto Forward Equivalence Classes (FECs) by ingress routers

123


according to the longest prefix match between the packet IPdestination and the IP addresses in the routing table. Then,MPLS packets are routed according to a new header knownas label [37]. In IPv6, packet headers already include a ded-icated bit-field for flow assignment. Since hICN reuses IPv6routing protocols, an hICN network can perform flow-basedrouting like any other IPv6 network [14]. In comparison, theIP-over-PURSUIT solution also allows flow-based routingby assigning delivery paths to packets based on the longestaddress prefix match. Furthermore, the match is done againstthe IP namespace of the RV in a centralized manner, facili-tating flow management. In addition to flow-based routing,IP-over-PURSUIT allows path-based routing through whichnew/updated delivery paths can be included in packet headerswithout waiting for flow rule updates to disseminate throughthe network.

ForMPLS to forward packets along Label Switched Paths(LSPs), routers need to maintain tables matching labelsagainst next-hops, known as Incoming Label Maps (ILMs).Moreover, routers also need to swap packet-labels on a hop-by-hop basis [19,37].On top of these,MPLS routers typicallyexecute link-based routing protocols such as OSPF to moni-tor the state of links and IP routing tables. Consequently, therequiredmemory and processing powerwithinMPLS routersincrease with the number of links [38]. In contrast, SDNswitches in IP-over-PURSUIT are simple forwarders sincelink-state information is managed by the RV/TM [16,39].Furthermore, these switches require fewer resources thanin the majority of flow-based IPv6/hICN solutions, giventhat flow tables only need to account for the switch ownlinks and routing decisions are based on bit-field matching[19]. From an SDN viewpoint, this implies that controller-to-switch interaction is limited to topology changes and thecost of integrating SDN switches is constant regardless of theconveyed traffic.

For the control plane to scale up, MPLS networks aredivided into levels, thus reducing the size of ILMs in indi-vidual routers [37]. Similarly, in IP-over-PURSUIT thescalability of the FWD requires zones due to the limitedlength of FIDs. While MPLS packets can traverse severallevels by stacking multiple labels in the same packet, PUR-SUIT packets carry as many FIDs as traversed zones. Thus,MPLS routers in-between levels behave similarly than IP-over-PURSUIT inter-zone routers since both swap labels andFIDs, respectively [20,38]. As with other SDN-based solu-tions, IP-over-PURSUIT also needs to divide the network tobalance the load between SDN-controllers, albeit IP-over-PURSUIT enjoys a lower switch-to-controller interaction.In contrast to other NFV-based solutions, the NFV-basedRV/TM needs to additionally manage pub/sub information.Nevertheless, in the use case 1, pub/sub information is lim-ited to the subscriptions on IP prefixes and subnets.

MPLS is widely used in IP networks to facilitate traf-fic engineering via LSP tunnels. In contrast, the IP-over-PURSUIT solution provides comparable, or even superiorfeatures since network-wide information on link-state iscentralized in the RV/TM. This might not be the case forMPLS since LSPs are established between ingress and egressrouters with partial network information [38]. Other flow-based IPv6/hICN solutions that implement control via SDNcan also provide similar traffic engineering capabilities.

IP-over-PURSUIT advantages and drawbacks:

+ Forwarding decisions are more efficient and requirefewer resources than substitutes.+ Comparable or even superior traffic engineering capa-bilities than substitutes.+ Unlike flow-based IPv6 solutions, SDN switch-controller interaction is low.- Substitutes based on MPLS/IPv6 are market-ready.

Use case 2: multicast routing The IP multicast protocol addsa tree-building protocol (e.g., PIM) and a rendezvous func-tion (e.g., IGMP) on top of IP, requiring individual routersto maintain per-flow state. Conversely, IP multicast can beprovided in an IP-over-PURSUIT network while maintain-ing routers almost stateless, i.e., except for inter-zone routers[19]. This advantage is maintained against hICN and MPLS.hICNrelies on IPv6 toperformmulticast andData packets arerouted using IPv6 multicast group addresses instead of nameprefixes [14]. In MPLS, additional memory and processingare required in routers, given that P2MPLSPs are establishedby an additional protocol named Multipoint-LDP [40].

HTTP has been adopted as the main delivery protocol totransfer video chunks from content servers to end users. InIP-over-PURSUIT, HTTP can enjoy coincidental multicastthus responses to the same chunk request can be bundledinto a single multicast response over the ICN network. Sincegateways restore unicast responses towards clients, trafficload can be reduced in proportion to the number of concurrentviewers.6

New multicast solutions are being developed in the IETFBit Index Explicit Replication (BIER) group. To be pre-cise, BIER encapsulates IP packets with an additional headerindicating multiple egress routers through which the packetshould exit the network [41]. Although the BIER solutionmight be able to eliminate the per-flow state in routers andexplicit tree-building protocols, it still acts as an extension tothe IP architecture. Therefore, routers in the BIER network

6 Concurrency is defined within an interval related to the chunk length,often several seconds, rather than requiring strict concurrency in themillisecond range.

123


might need to manage BIER-specific forwarding tables andshare information with link-based routing protocols, suchas OSPF. Unless BIER networks adopt a gateway-basedarchitecture, they cannot apply the multicast to IP-basedprotocols, e.g., HTTP coincidental multicast, nor enforcerouting policies, e.g., FQDN-based or delay-based policies.Such addition of gateways for multicast delivery of HTTPresponses has been proposed in [42].


+ IP multicast can be implemented without storing per-flow state in routers.+ Routing policies can be established based on FQDNand delays.+ Unlike IPv6, the distribution of HTTP data can beoptimized via HTTP coincidental multicast.

Use case 3: service routing To enable IP mobility, cur-rent 3GPP-based mobile solutions channel UE-generatedtraffic towards the core network via GPRS Tunneling Pro-tocol (GTP) tunnels, impeding access to edge services. Toaddress this issue, the 3GPP specification for 5Gmobile sys-tems enable local routing and traffic steering [34]. Thus, the5G core network will support UE access to the so-called“local area data network” in which edge applications willbe deployed. Service continuity will be guaranteed for cer-tain mobility scenarios assigning multiple anchor points toa single session, i.e., one anchor point for each data net-work, including the telco cloud and the edge cloud [43].In contrast to 3GPP-based solutions, operators deployingIP-over-PURSUIT can enjoy anchorless mobility, allowingdelivery paths to follow the optimal route and avoiding net-work bottlenecks. Furthermore, IP-over-PURSUIT enablesthe continuity of HTTP sessions after a handover via fastservice indirection [23].

Furthermore, the availability of emerging surrogate ser-vices can be directly notified to client-facing NAPs, avoidingDNS propagation delays across caches on access pointsand clients. In this context, the IP-over-PURSUIT solutionaims to remain compatible with the current specificationMEC [44]. In fact, MEC edge applications are managedthrough a pub/sub system like IP-over-PURSUIT servicerouting [45]. If we extend our comparison to include hICN,this routing technology also allows anchorless mobilitysince mobile UE can redirect in-flight Data packets to itsnew location by re-sending Interest messages through itsnew attachment point, thus creating a new reverse path.For this, hICN does not require rendezvous-based rematchof pub/sub information. Further, hICN also allows serviceindirection since routers can associate different sourcesof the same content to different outbound interfaces of

routers. However, switchovers from old to new emergingcontent sources might be slow due to packet propagationdelays.


+Edge content ismade directly available toNAPs avoid-ing DNS/CCN propagation delays.+ Unlike IPv6, connections can be seamlessly switchedbetween HTTP surrogate services.+Unlike IPv6, anchorless mobility and decoupling of IPaddresses and UE location.- Unlike hICN, rendezvous-based pub/sub matching isrequired for mobility.

3.5.2 Advantages and drawbacks compared to IP-over-CCNimplementations

Use case 1: flow-based routingAn IETF Internet draft existsdescribing how IP can be tunneled over CCN [14]. Accord-ing to this draft, IP gateways need to become content sourcesand disseminate their associated content name, i.e., the IPaddress space or prefix they serve, through the CCNnetwork.Therefore, IP traffic generated by UE can be encapsulated inInterest messages that have the egress gateway as the con-tent name. After the egress gateway receives the IP responsefrom the Internet, it forwards this back encapsulated in Datamessages. To ensure that a reverse path exists for as manyDatamessages as the IP response may require, UEmay needto send additional Interest messages, thus keeping enoughactive entries in routers’ PIT. At the same time, IP gatewayshave to maintain an ordered queue of content names thathave been requested by each client, namely the Client Inter-est Table (CIT). Thus, UE and IP gateways collaborate byadjusting the number of in-flight messages according to PITentry lifetimes, in what may resemble TCP window adver-tisements. This IP tunneling solution creates pub/sub state inIP gateways since content requested by clients is stored inCITs. While this approach may create a dispersed pub/substate that is difficult to manage, IP-over-PURSUIT providesa rendezvous-based solution with a scalable design. Further,it does not dedicate gateway resources to artificially maintainreverse paths.

None of the existing IP-over-CCN implementations definehow flow-based routing could be performed. Intuitively, itis clear that IP packets that enter a CCN network can beaggregated to become a single flow by encapsulating themin Interest/Data packets the content name of which includesthe same egress gateway. For this, ingress routers need toassign the content name of egress gateways to Interest/Datapackets according to the destination address of IP packets,

123


similarly to MPLS. Based on this assumption, we suggestthat IP-over-PURSUIT enjoys, at least, the same advantagescompared to IP-over-CCN than to IP-based solutions. First,IP-over-PURSUIT implements more efficient routing deci-sions using significantly fewer resources than CCN routers,given its stateless forwarding. Second, flow managementcan be centrally controlled through the IP namespace in theRV. Third, IP-over-PURSUIT can potentially perform trafficengineering features via the TM.


+ Forwarding decisions are more efficient and requirefewer resources than substitutes.+ Pub/sub state is centrally managed via a rendezvous+Reverse paths do not need to be artificially maintained.+ More mature specification of the generic IP handlingapplication

Use case 2: multicast routing Two implementations existdescribing how HTTP could be transported over CCN,improving the delivery of heavy content. In the first imple-mentation [46], CDN caches are substituted by CCN routersequipped with Content Storage. These routers need CCN-to-HTTP translation to request content from higher levelcaches (or other HTTP sources) and, they also need HTTP-to-CCN translation to understand client requests. The maintechnical difficulty is found in the CCN-to-HTTP transla-tion since HTTP gateways need to generate CCN manifests,which are included in Data messages providing a list ofcontent objects and associated signatures. Since these man-ifests cannot be constructed until the full HTTP responseis received, CCN-based communication is stalled. Althoughmulticast routing ismentioned in [46], no detailed implemen-tation is described. Moreover, HTTP gateways are placedimmediately after content sources, shortening potentiallyshared data paths andminimizing multicast gain. The secondHTTP-over-CCN implementation adopts a generic architec-ture positioning HTTP gateways at the border of any CCNnetwork [47]. These gateways translate GET and POSTmethods into a sequence of Interest/Data packet flows. Incontrast to the first implementation, IP responses are splitinto small chunks which are immediately exchanged as inde-pendent data objects. Although this second implementationcould potentially implement a coincidental multicast mech-anism by aggregating HTTP requests in ingress gateways,this is not described in the specifications document. More-over, none of the two cited implementations describe how IPgateways keep track of HTTP requests when sent by differentUE.


+ A more mature specification of the HTTP handler.+ HTTP handler implements HTTP coincidental multi-cast.

Use case 3: service routing The authors have not found anyscientific publications or technical specifications that definehow the indirection of IP-based services can be performedover CCN. Nevertheless, if a new source of already exist-ing content would be made available to the CCN networkby an IP gateway, this information would need to propagatethrough CCN routers until other IP gateways become aware.In contrast, IP-over-PURSUIT allows the direct notificationof those IP gateways currently serving that content item.


+Edge content ismade directly available toNAPs avoid-ing CCN propagation delays.- Rendezvous-based pub/sub matching is required formobility.

3.6 Feasibility analysis

This section identifies and evaluates the key technical andbusiness factors that can dispute the potential benefits ofIP-over-PURSUIT and potentially discourage stakeholderadoption. Table 5 presents the feasibility challenges iden-tified in previous sections and evaluates the ability ofIP-over-PURSUIT to address them for each use case. Basedon the evaluation results, we further study the challengeswith an unknown feasibility outcome and we suggest possi-ble solutions for the challenges that dispute the feasibility.

3.6.1 Challenge 2: routing scalability

The routing scalability of the IP-over-PURSUIT solution isconstrained by the scalability of its network functions. Asdescribed in Sect. 2.6, while the FWD is supported by thezoning mechanism, the RV and the TM are supported bythe NFV-based RV/TM. Both mechanisms divide the net-work into zones and assign resources to the managementof these zones. Since the current specification of the IP-over-PURSUIT solution does not provide guidelines on howthe network should be divided, we decide to evaluate themechanism that addresses the most challenging scalabilitybottleneck. The scalability of the FWD is the most criticalsince it equally affects all three use cases under study. Notethat the RV/TM might not present an immediate scalabilitychallenge for use case 1, given that the RV only needs to storethe IP namespace. Although the scalability of rendezvous

123


Table 5 Feasibility challenges

Feasibility challenge Flow-based routing Multicast routing Service routing Evaluated in

1 Can the architecture design servethe use case needs?

√ √ √Technical architecture analysis(see Table 3)

2 Can the scalability mechanismsenable routing for nation-sizedtopologies?

? ? −a Technical architecture analysis

3 Can the architecture design providetechnical advantages in comparisonto substitute solutions?

√ √ √Deployment environment analysis

4 Can the architecture design provideenoughbenefits forOTTvideoplay-ers to sign a content distributioncontract?

– ×b – Value network analysis(see Table 4)

5 Can the architecture design provideenoughbenefits for edge applicationproviders to sign a service surrogacycontract?

– – ×c Value network analysis

6 Is the implemented solution IPinteroperable?

? ? ? Value network analysis

√ = yes; ? = not known yet; × = disputed; − = the use case is not affectedaService routing is not affected by the challenge 2 since adoption is limited to micro-operators or MNOs on the edge cloudbThe release of operator link capacity via HTTP coincidental multicast does not immediately benefit OTTscEdge application providers cannot remotely monitor service quality or control switchover between surrogates

functions implementing an Internet-scale model have beenstudied in the past, results do not apply here [48].

The technical feasibility of the FWD has been extensivelystudied via simulations as an enabler for stateless multicastsolutions [17,18]. More recently, it has been demonstratedthat the FWD can be implemented with existing SDNswitches with less state than existing unicast switching solu-tions [19]. In addition, to guarantee the FWD scalability,a zoning mechanism has been proposed implementing theExtensible Bloom Filter (XBF) approach [20]. In the con-text of XBF, researchers have studied the delay introducedby inter-zone routers [49] and, they have devised a segmen-tation method that minimizes the inter-zone forwarding [20].Although this segmentation method reduces the number ofinter-zone operations, it does so by increasing the numberof inter-zone routers, increasing deployment and manage-ment costs and challenging economic scalability. Therefore,we decide to study a new segmentation method for the XBFapproach that minimizes the number of inter-zone routers. Tothis end, (a)we demonstrate how theXBF zoningmechanismenables the creation of zones, (b) we present our segmenta-tion method, and (c) we finally evaluate the scalability of theresulting FWD function.

(a) The XBF approach enables the creation of zones inan IP-over-PURSUIT network. Table 6 shows how thenumber of zones can be increased by dividing thespace reserved for FIDs (256 bits, the combined sizeof the IPv6 source and destination addresses) into ZIDs

(zones) and zone-specific FIDs [50]. Each bit added tothe ZID length doubles the numbers of zones, while itdecreases the number of links per zone by one. As aresult, the number of total unidirectional links is almostdoubled with each new zone. Note that positions in theFID are only used to identify one link per zone, thuspreventing false positives in packet forwarding.

(b) Themain idea behind our segmentationmethod is to addlinks to a zone until the maximum number of links perzone is reached.At this point, we create a new zone. Thisprocess starts from the bottom of the topology and isrecursively repeated until core links are reached. Giventhat links between NAPs and clients remain IP, the seg-mentationmethod starts by groupingNAPs in the accesslayer.7 At this point, if the node degree of the distribu-tion layer is smaller than themaximum number links perzone, then all NAPs hanging from a node in the distribu-tion layer belong to the same zone, including the nodein the distribution layer. Otherwise, multiple zones needto be created for each node in the distribution layer, andthis node becomes an inter-zone router.

(c) We assess the scalability of the FWD function for anetwork topology that approximates a mobile opera-tor serving approximately 2.4 million users, which is

7 Recent work in 3GPP Release 16 on vertical, cellular LAN specifiesthe use of path-based forwarding between core and access nodes only,i.e., the user plane functions in cellular networks, while utilizing LAN-based communication to reach UE.

123


Table 6 XBF zoning segmentation

ZID (bits) sFID (bits) Zones Unid. links UE

2 254 4 1016

3 253 8 2024

4 252 16 4032 1 106

5 251 32 8032 2 106

6 250 64 16,000 3 106

derived from Mobile Network Operator (MNO) inter-views in Finland [51]. Although this topology followsa simple hierarchical model, it captures the deploymentstructure of commercial access operators with a nation-wide presence, in contrast to topologies from researchnetworks or topology generators. This decision is coher-ent with the objectives of the study that aims at assessingmarket feasibility. More importantly, the selected topol-ogy addresses the minimum deployment requirementsof stakeholders identified as possible adopters duringthe value network analysis, i.e., IP-connectivity opera-tors, triple play operators, MNOs, and micro-operators.As shown in Fig. 5, the topology is determined by nodedegrees of 714, 5, and 161 in the access, distribution andcore layers, respectively. In each layer, nodes serve thesame number of slaves and are connected to only onemaster (e.g., nodes in the transport layer have a nodedegree of 5 meaning that they are connected to 4 slavenodes on the access layer and to 1 master node on thecore layer).

To estimate the number of required zones, we simulate agrowing topology that gradually adds nodes to access, distri-bution, and core layers up to their maximum node degree byincreasing the number of subscribers. Results show that thestudied topology could be served using zones with 250 uni-directional links, as shown in the last row of Table 6. Sincethe node degree of distribution nodes is 10 (4 bidirectionallinks to access nodes and 1 bidirectional link with a corenode), each core node can handle up to 25 distribution nodeswithout adding a new zone. This implies that only core nodesneed to become inter-zone routers.

The next step in the scalability analysis is to identify howmany zones each inter-zone router would need to handle.Based on the same simulation, Fig. 6 shows that althoughthe number of total zones (in circles) increases with sub-scribers, the zones per core router vary between 1 and 7 (inrectangles). Figure 7 shows this same variation in parallelwith the increase in the number of core routers (in triangles).This variation is caused by the assignment of zones to corerouters, as new core routers are added to the topology.

Internet GW,Telco cloud

Core

Distribution

Access(NAP)

Subscribers(UE)

1 .. 6

1 .. 4

1 .. 714

1 .. 160

1

Fig. 5 Topology structure of a Finnish mobile operator

Fig. 6 Growth in the number of zones

Fig. 7 Zones per router

This study reveals that inter-zone forwarding is onlyrequired in core nodes, similar to the OSPF zone 0 approach.More importantly, as the number of required zones grew

123


to accommodate new links and subscribers, the number ofzones per router remained below 8. However, this zoningsolution requires further study since the topology does notaccount for redundant links. Moreover, the payload of thePURSUITpacket needs to carry not only IP data, but also pig-gybacked FIDs. As a result, the ICN packet might grow andsuffer layer-2 segmentation. At the current state of develop-ment, the IP-over-PURSUIT solution presents lighter zoningrequirements than the OSPF recommendation by Cisco.Cisco guidelines on the configuration of OSPF recommend50 routers per area, 3 areas per ABR, and a maximum nodedegree of 60 [50].

3.6.2 Challenge 4 and 5: stakeholder benefits

According to the value network analysis, operators need totake control over the provision of OTT content and over theprovision of surrogate services to fully benefit from multi-cast routing and service routing, respectively. However, OTTproviders and edge application providers might not be will-ing to concede this control since their role in the provision ofcontent and services would be downgraded to content ownersand application developers, respectively. For example, OTTproviders are not interested in operators releasing core linkcapacity via HTTP coincidental multicast if, in return, theylose control over service provision.

Similarly, edge application providers might not be inter-ested in HTTP service indirection if they need to competewith other providers for NAPs to switchover their con-nections. Therefore, these providers have little incentiveto collaborate with an IP-over-PURSUIT operator inde-pendently of the operator-specific benefits, given that, inIP-based networks, these providers canmaintain their currentsuperior business roles. Without these providers concedingcontrol, the benefits obtained by the operator might not beenough to justify the adoptionof IP-over-PURSUITover sub-stitute solutions, such as IP-based solutions.

However, the potential reductions in costs through HTTPcoincidental multicast or latency through HTTP serviceindirection may eventually yield benefits for OTTs/edgeapplication providers, thus making it desirable to reconciletheir need in obtaining useful service delivery informationwith the need of operators to have more control over thedelivery. In operator-OTT negotiations, the latter may enjoya stronger position, as demonstrated by the remote controlthat OTTs have over caches which are placed within operatornetworks, e.g., Google Global Cache, Netflix Open Connect.

To overcome this feasibility challenge, we suggest theimplementation of technical interfaces allowing providers toremotely access the RV (and maybe strategic NAPs) to mon-itor technical and business information about their own con-tent and services, i.e., providers can monitor service qualityand account for service usage. By offering these new techni-

cal interfaces, operators create a win-win situation in whichtheir newand cost-effective routing capabilities could be usedwithout challenging the current business roles of providers.For the multicast routing use case, an OTT-operator interfaceneeds to inform in real-time about the quality of the servicedelivery and usage statistics, matching the current informa-tion/control through HTTP/HTTPS. For example, this newinterface needs to allow content providers to deliver per-sonalized adverts, retrieve click counts, etc. For the servicerouting use case, an edge application provider-operator inter-face needs to allow providers to remotely control the promptswitchover of connections between surrogate services, e.g.,according to NAP load. Similar inter-stakeholder interfacesexist in the Internet allowing remote access to MNO sys-tems by Mobile Virtual Network Operators via Policy andCharging and Control interfaces [52].

3.6.3 Challenge 6: IP interoperability

The IP-over-PURSUIT solution was trialed to provide Inter-net access to 45 households near the city of Barcelonain Spain, using a newly deployed wireless network madeof six nodes, as shown in Fig. 8 [53]. The trial networkincluded all the elements in the IP-over-PURSUIT archi-tecture which were deployed in software, including OpenvSwitch switches. While all six nodes executed FWD andNAP functions, only one node executed theRV/TMand actedas the only Internet gateway. While the transport of HTTPdata over the PURSUIT network was managed by HTTPhandlers, the rest of the IP data (non-HTTP) has been indis-tinguishably managed by IP handlers.

The field trial has demonstrated for the first time that realIP traffic can be successfully routed over an ICN networkwithout modifying UE or applications [53]. Furthermore,measurements accounting for 15 days of network activ-

Fig. 8 Field trial topology [53]

123


Table 7 Measured peakthroughputs in the Barcelonatrial [53]

Protocol Peak RX (Mbps) Peak TX (Mbps)

Client-facing NAP HTTP 0.187 8

Client-facing NAP non-HTTP 1.8 8

Internet-facing NAP HTTP 10 0.063

Internet-facing NAP non-HTTP 9 2

ity between a client-facing NAP and the Internet-facingNAP revealed peak throughput values within the expectedrange. As shown in Table 7, data transmission (TX) andreception (RX) achieved peak values between 8 and 10Mbps, respectively. These values approximately correspondto the maximum throughput achievable with the deployedequipment which was resource constrained. To be precise,laboratory deployments with similar resource-constrainedequipment achieved throughputs no larger than 12 Mbps.Note that non-constrained laboratory measurements haveachieved NAP-to-NAP throughputs up to 85 Mbps.

In addition to IP interoperability, the trial demonstratedthat specific routing behavior can be applied to individualprotocols by handlingHTTP traffic independently fromotherIP protocols. However, measurements revealed that HTTPonly accounted for a tiny 0,666% of the total traffic. More-over, only 4 IP addresses were detected accessing HTTPservices simultaneously. Under these conditions, the HTTPcoincidentalmulticast could not have provided any efficiencygains to the underlying transport network. This result is con-sistent with the trend observed in other networks in whichHTTP is rapidly substituted by HTTPS and emphasizes theimportance of the upcoming feasibility challenge on theCon-trol over the provision of OTT content. Finally, from anoperational point of view, the trial also demonstrated thatoperators can gradually deploy ICN on their IP networks onelink at a time [53].

3.7 Solution analysis

In this section, we discuss operator adoption of IP-over-PURSUIT as a single network routing solution (i.e., as IGP)depending on positive net benefits of stakeholders taking intoaccount the operator service offering and the general marketconditions.

Any operator that adopts the IP-over-PURSUIT routingsolution will remain interoperable with IP networks and UE,as demonstrated by a field trial. More importantly, the IPintegration is straightforward since NAPs manage publica-tions and subscriptions based on IP address prefixes. Further,our initial calculations suggest that IP-over-PURSUIT couldserve nation-sized network topologies while keeping thenumber of inter-zone routers under a reasonable upper bound.However, further study is required to framewith precision the

scalability requirements of the RV/TM for content-intensiveuse cases.

Connectivity operators might be interested in IP-over-PURSUIT since it enables flow-based routing. In contrastto substitute solutions, IP-over-PURSUIT facilitates the fre-quent update of flow paths through a light SDN integration.Flow paths are easily updated since these are centrally com-puted by the RV/TM and only disseminated to NAPs whenrequested by new service queries. Furthermore, operatorscan reuse preexisting SDN switches, integrate SDN switchesmore efficiently than current SDN solutions, and enjoy alower controller-to-switch interaction. Thus, the IP-over-PURSUIT solution can delay and reduce capital expenditure(CAPEX) by reusing existing equipment and by acquiringequipment with less memory and computing power. Fur-ther, it can also reduce operational expenditure (OPEX) bysimplifying flow management. Regarding stakeholder col-laboration, no new or unusual business contracts need to besigned for operators to enjoy the use case benefits. However,IP-over-PURSUIT will encounter fierce competition frommarket-ready solutions implementing IPv6.

Connectivity operators that also provide content-basedservices might be interested in IP-over-PURSUIT since itenables the multicast of media content. For example, tripleplay operators that either own or plan to acquire contentdistribution rights have a greater incentive to adopt IP-over-PURSUIT routing solutions since they can continuecontract-based content distribution via IP multicast. Further,IPTV services would gain in scalability, increasing the max-imum number of synchronous viewers, given that P2MPtransmissions do not store per-flow state in nodes. Further-more, triple play operators could spare capacity in core linksby delivering OTT traffic via HTTP coincidental multicast ifOTT providers facilitate the proxy of HTTPS connections.While small content providers might allow this proxy, largeOTTs likeNetflixmight not since their owndelivery solutionsguarantee a direct technical and contractual relationship withconsumers via HTTPS and they do not obtain an immediatebenefit from IP-over-PURSUIT. To address this challenge,operators need to convince OTTs that their business role ascontent providers is not challenged by IP-over-PURSUIT,e.g., by offering real-time information over the delivery ofcontent through a new OTT-operator technical interface, byoffering economic incentives when deploying caches within

123


operator networks. In terms of OPEX, the ability to cen-trally manage link-state and pub/sub information throughthe RV/TM can be a relevant differentiator against substitutesolutions. Further, triple play operators might also be inter-ested in introducing FQDN-based and delay-based routingpolicies.

It is unlikely that MNOs adopt IP-over-PURSUIT as arouting solution for the edge cloud since NAPs are notcompatible with 3GPP signaling protocols enabling trafficsteering to the edge cloud. As a result, HTTP service indi-rection between surrogate services in the telco and edgecloud is currently not possible. Nevertheless, recent devel-opments in the release 15 of 3GPP specification for 5G mayfacilitate this integration, given the service-based architec-ture. Micro-operators covering a limited geographical areamight be interested in adopting IP-over-PURSUIT as an IGPsolution. In comparison to small-scale 3GPP-based solutionslike MuLTEfire [54], IP-over-PURSUIT micro-operatorscould provide anchorless mobility and fast HTTP serviceindirection to low-latency applications via Wi-Fi. How-ever, if micro-operators open the edge cloud to third-partyapplications, application providers might require real-timeinformation and control over the HTTP service indirectionto guarantee service quality.

4 IP-over-ICN deployment strategy

The long-term IP-over-ICN deployment strategy aims toestablish a fully ICN-based Internet architecture in whichInternet stakeholders interconnect based on informationitems [11]. This information-based interconnection canpotentially reduce inter-domain traffic, although a criticalmass of adopters is required to unleash significant net-work effects. Next, we study the key challenges delayinginformation-based interconnection between Internet stake-holders.

CDN-to-CDNinterconnection is technically feasible sincemostCDNs implement contentmanagement systems, includ-ing pub/sub, e.g., Akamai [55]. However, CDNs have littleincentive to interconnect since they compete for the samecontent items/owners. If operators adopt ICN-based rout-ing systems, their willingness to share valuable content viaoperator-to-operator interconnection is also limited whencoverages overlap since they compete for the same con-sumers. When coverages do not overlap, operators cannotshare valuable content since distribution rights are typicallyexclusive for their coverage area. Moreover, the infrastruc-ture of operators is not typically needed for global contentdistribution since content providers use CDNs.

Finally, operator-to-CDN interconnection can unleashsubstantial benefits for operators as studied for the multicastrouting use case. However, this interconnection gives oper-

ators control over the provision of content, thus preventingcontent providers from monitoring content consumption. Asa first consequence of this interconnection, CDNs may losethe ability to differentiate based on the Quality of Service(QoS). As a second consequence, depending on the IP-over-ICN implementation, content providers might not be ableto establish direct contractual relationships with consumersnor provide personalized ads. Therefore, it is unlikely thatcontent providers accept the CDN-to-operator interconnec-tion, given that content is already delivered successfully viaCDNs. In fact, OTT providers enjoy a dominant positionon today’s provision of content since OTTs keep controlover caches which are placed within operator networks, e.g.,Google Global Cache, Netflix Open Connect.

Hence, the advent of an ICN-based Internet architecturemay be delayed until Internet stakeholders have enoughincentives to delegate the delivery of valuable content andservices. For this, inter-stakeholder technical and businessinterfaces need to emerge enabling trustworthy collaborationand compensation in future information-based interconnec-tion points. For example, allowing stakeholders to chargeone another for the delivery of copyrighted content throughpay-per-delivery schemes, e.g., via smart contracts.

5 Conclusions

This article assesses the feasibility of IP-over-PURSUITas single network routing solution for flow-based routing,multicast routing, and service routing use cases. First, wesuggest that these use cases can be successfully servedby the solution, albeit different but compatible architec-ture configurations are required. Second, we indicate thatIP-over-PURSUIT potentially offers technical advantages incomparison to substitute solutions for the three use cases,including efficient forwarding, light SDN integration, almoststateless HTTP coincidental multicast, and fast HTTP ser-vice indirection. Third, the routing solution does not presentimmediate challenges regarding IP interoperability and rout-ing scalability, as indicated by field trial evidence and thezone-based forwarding assessment, respectively. Fourth, wesuggest that the IP-over-PURSUIT architecture should adoptnew exterior interfaces since its current design may not pro-vide enough stakeholder-specific benefits. Note that OTTsand edge application providers need to concede control overthe provision of content and services for a significant fractionof the operator traffic to be delivered through HTTP coinci-dental multicast and HTTP service indirection.

We suggest that triple play operators owning contentdistribution rights have incentives to adopt the IP-over-PURSUIT solution since they can continue contract-basedcontent distribution via scalable IP multicast. Further, tripleplay operators can spare capacity in core links by deliv-

123


ering OTT traffic via HTTP coincidental multicast if OTTproviders are provided with remote service monitoring capa-bilities. The more traffic triple play operators can deliverthrough multicast, the larger the motivation to adopt IP-over-PURSUIT. In addition, the ability to centrally managelink-state and pub/sub information through a light SDNintegration can be a relevant differentiator for operatorsagainst substitute solutions. In addition to triple play oper-ators, micro-operators covering a limited geographical areamight also be interested in adopting IP-over-ICN to provideanchorlessmobility and fastHTTPservice indirection to low-latency applications via Wi-Fi.

Finally, we indicate that the advent of an ICN-based Inter-net architecture via the IP-over-ICN deployment strategymight be delayed until Internet stakeholders can delegate thedelivery of valuable content and services via automatic com-pensation schemes in information-based exchange points.

The IP-over-PURSUIT routing solution will be furtherdeveloped in the H2020 FLAME project to provide flexi-ble routing of IP services following a Service as a platformmodel. In this context, IP-over-PURSUIT has been recentlyapplied to service routing in 5Gcore networks through effortson service-based architecture in 3GPP Release 15.

Acknowledgements Open access funding provided by Aalto Uni-versity. The authors would like to thank Arto Karila and PekkaNikander for their valuable comments and discussions. This work wassupported by the EC H2020 RIFE Project Grant No. 644663 and by theEC H2020 POINT Project Grant No. 643990.

Compliance with ethical standards

Conflict of interest Dr. Dirk Trossen is directly involved in the develop-ment of IP-over-PURSUIT solutions at InterDigital. The other authorshave no conflict of interest.

Open Access This article is distributed under the terms of the CreativeCommons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution,and reproduction in any medium, provided you give appropriate creditto the original author(s) and the source, provide a link to the CreativeCommons license, and indicate if changes were made.

References

1. Koponen, T., Chawla, M., Chun, B.-G., Ermolinskiy, A., Kim, K.H., Shenker, S., et al. (2007). A data-oriented (and beyond) networkarchitecture. ACM SIGCOMM Computer Communication Review,37(4), 181–192.

2. Jacobson, V., Smetters, D. K., Thornton, J. D., Plass, M., Briggs,N., & Braynard, R. (2012). Networking named content. Commu-nications of the ACM, 55(1), 117–124.

3. Trossen, D., & Parisis, G. (2012). Designing and realizing aninformation-centric internet. IEEE Communications Magazine,50(7), 60–67.

4. Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren,B., & Karl, H. (2013). Network of information (NetInf)—Aninformation-centric networking architecture. Computer Commu-nications, 36(7), 721–735.

5. Handley, M. (2006). Why the Internet only just works. BT Tech-nology Journal, 24(3), 119–129.

6. Turner, J. S., & Taylor, D. E. (2005). Diversifying the Internet. InGLOBECOM—IEEE global telecommunications conference.

7. Clark, D. D., Wroclawski, J., Sollins, K. R., & Braden (2002).Tussle in cyberspace. In Proceedings of the 2002 conference onapplications, technologies, architectures, and protocols for com-puter communications—SIGCOMM ’02, no. 4. New York, NY:ACM Press.

8. Clark, D. D., Wroclawski, J., Sollins, K. R., & Braden, R. (2005).Tussle in cyberspace: Defining tomorrow’s internet. IEEE/ACMTransactions on Networking (ToN), 13(3), 462–475.

9. Kostopoulos, A., Papafili, I., Kalogiros, C., Levä, T., Zhang, N.,& Trossen, D. (2012). A tussle analysis for information-centricnetworking architectures. In F. Álvarez, et al. (Eds.), The futureinternet (pp. 6–17). Berlin, Heidelberg: Springer.

10. Agyapong, P. K., & Sirbu, M. (2012). Economic incentives ininformation-centric networking: Implications for protocol designand public policy. IEEE Communications Magazine, 50(12), 18–26.

11. Trossen, D., & Kostopoulos, A. (2011). Exploring the tussle spacefor information-centric networking. In Telecommunications policyresearch conference (TPRC). Social Science Research Network(SSRN). https://ssrn.com/abstract=1979924.

12. Rahman, A., Trossen, D., Kutscher, D., & Ravindran, R. (2019).Deployment considerations for information-centric networking(ICN). Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-deploymentguidelines-06.

13. Muscariello, L., & Engineer, P. (2018).Hybrid information-centricnetworking ICN inside the Internet protocol. https://datatracker.ietf.org/meeting/interim-2018-icnrg-01/materials/slides-interim-2018-icnrg-01-sessa-hybrid-icn-hicn-lucamuscariello.

14. Muscariello, L., Carofiglio, G., Auge, J., & Papalini, M.(2018). Hybrid information-centric networking. Internet Engi-neering Task Force. https://datatracker.ietf.org/doc/html/draft-muscariello-intareahicn-00.

15. Levä,T.,&Suomi,H. (2013).Techno-economic feasibility analysisof Internet protocols: Framework and tools. Computer Standardsand Interfaces, 36(1), 76–88.

16. Xylomenos, G., Al-Khalidi, M., Al-Naday, M., Fotiou, N., Karila,A., Petropoulos, G., et al. (2018). H2020 POINT D2.4 scenarios,requirements, specifications and KPIs. Technical report 643990.

17. Fotiou, N., Trossen, D., & Polyzos, G. C. (2012). Illustrating apublish-subscribe Internet architecture. Telecommunication Sys-tems, 51(4), 233–245.

18. Jokela, P., Zahemszky, A., Rothenberg, C. E., Arianfar, S., &Nikander, P. (2009). LIPSIN: Line speed publish/subscribe inter-networking. Design, 39(4), 195–206.

19. Reed, M. J., Al-Naday, M., Thomos, N., Trossen, D., Petropoulos,G., & Spirou, S. (2016). Stateless multicast switching in softwaredefined networks. In 2016 IEEE international conference on com-munications, ICC 2016.

20. Antikainen, M., Wang, L., Trossen, D., & Sathiaseelan, A.(2016). XBF: Scaling up bloom-filter-based source routing.arXiv:1602.05853.

21. Trossen, D., Reed, M. J., Riihijärvi, J., Georgiades, M., Fotiou,N., & Xylomenos, G. (2015). IP over ICN-the better IP? In 2015European conference on networks and communications (EuCNC).

22. Xylomenos, G., Al-Naday, M., Fotiou, N., Karila, A., Petropou-los, G., Reed, M. J., et al. (2016). H2020 POINT D2.3 scenarios,requirements, specifications and KPIs, 3rd version. Technicalreport.

123

http://creativecommons.org/licenses/by/4.0/

http://creativecommons.org/licenses/by/4.0/

https://ssrn.com/abstract=1979924

https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-deploymentguidelines-06

https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-deploymentguidelines-06

https://datatracker.ietf.org/meeting/interim-2018-icnrg-01/materials/slides-interim-2018-icnrg-01-sessa-hybrid-icn-hicn-lucamuscariello



https://datatracker.ietf.org/doc/html/draft-muscariello-intareahicn-00

https://datatracker.ietf.org/doc/html/draft-muscariello-intareahicn-00

http://arxiv.org/abs/1602.05853


23. Al-Khalidi, M. Q., Thomos, N., Martin, R., Al-Naday, M., &Trossen, D. (2018). Anchor free IP mobility. IEEE Transactionson Mobile Computing, 18, 56–69.

24. Rahman,A.,&Trossen,D. (2018).Alternative handlingof dynamicchaining and service indirection draft-purkayastha-sfc-service-indirection-01.

25. Levä, T., Mazhelis, O., & Suomi, H. (2014). Comparing the cost-efficiency of CoAP and HTTP in Web of Things applications.Decision Support Systems, 63, 23–38.

26. Levä, T., Komu, M., Keränen, A., & Luukkainen, S. (2013). Adop-tion barriers of network layer protocols: The case of host identityprotocol. Computer Networks, 57(10), 2218–2232.

27. Karakus, M., & Durresi, A. (2017). A survey: Control planescalability issues and approaches in software-defined networking(SDN). Computer Networks, 112, 279–293.

28. Rich, M. (2017). What behavioral data tells us about the OTTviewing habits of cord-cutters. comScore, Inc.

29. Enoch, G. (2016). The Nielsen total audience report—Q2 2016.Technical report

30. Telia Company acquires Bonnier Broadcasting - Telia Company.Retrieved August 2, 2018 from https://www.teliacompany.com/en/news/press-releases/2018/7/telia-company-acquires-bonnier-broadcasting/.

31. Bilal, K., Khalid, O., Erbad, A., & Khan, S. U. (2018). Potentials,trends, and prospects in edge technologies: Fog, cloudlet, mobileedge, and micro data centers. Computer Networks, 130, 94–120.

32. Casey, T., Smura, T., & Sorri, A. (2010). Value network config-urations in wireless local area access. In 2010 9th conference oftelecommunication, media and Internet, CTTE 2010. IEEE.

33. Benseny, J., & Hammainen, H. (2016). Value network analysis ina low-cost and affordable internet. In EUCNC 2016—Europeanconference on networks and communications.

34. Kekki, S., Featherstone, W., Fang, Y., Kuure, P., Li, A., Ranjan,A., et al. (2018). ETSI white paper no. 28 MEC in 5G networks.Technical report.

35. Suthar, P., Stolic, M., Jangam, A., Trossen, D., & Ravindran, R.(2018). Native Deployment of ICN in LTE, 4G Mobile Networks.Internet Engineering Task Force, Internet-Draft draft-irtf-icnrg-icn-lte-4g-02, work in Progress.

36. Walia, J. S., Hammainen, H., &Matinmikko,M. (2018). 5Gmicro-operators for the future campus: A techno-economic study. In Joint13th CTTE and 10th CMI conference on Internet of Things—Business models, users, and networks. IEEE.

37. Rosen, E., Viswanathan, A., & Callon, R. (2001). Multiprotocollabel switching architecture. Technical report.

38. Moy, J. (1998). OSPF Version 2. Technical report.39. Petropoulos, G., Katsaros, K. V., & Xezonaki, M. E. (2017).

OpenFlow-compliant topology management for SDN-enabledinformation centric networks. In Proceedings—IEEE symposiumon computers and communications.

40. Eckert, T., Leymann, N., & Napierala, M. (2013). MultipointLDP in-band signaling for point-to-multipoint and multipoint-to-multipoint label switched paths. https://doi.org/10.17487/rfc6826.

41. Dolganow, A., Przygienda, T., &Aldrin, S. (2017).Multicast usingbit index explicit replication (BIER). RFC 8279.

42. Purkayastha, D., Rahman, A., Trossen, D., & Eckert, T. (2018).Applicability of BIER multicast overlay for adaptive streamingservices. Internet Engineering Task Force, Internet-Draft draft-purkayastha-bier-multicast-http-response-01, work in Progress.Retrieved May 2, 2019 from https://datatracker.ietf.org/doc/html/draft-purkayastha-bier-multicast-http-response-01.

43. 3GPP TS 33.402. (2011). 3rd generation partnership project;technical specification group services and system aspects; 3GPPsystem architecture evolution (SAE); Security aspects of non-3GPPaccesses. 3GPP, Technical report v.11.2.0 - Release 11.

44. ETSI. (2018). GR MEC 017 - V1.1.1—Mobile edge computing(MEC); Deployment of mobile edge computing in an NFV envi-ronment. Technical report.

45. ETSI. (2017). Mobile edge computing (MEC); Mobile edge plat-form application enablement. Technical report.

46. White,G.,&Rutz,G. (2016).Content deliverywith content-centricnetworking. Cable Television Laboratories, Inc.

47. Wang, S., Bi, J., Wu, J., Yang, X., & Fan, L. (2012). On adaptinghttp protocol to content centric networking. In Proceedings of the7th international conference on future internet technologies (pp.1–6). ACM.

48. Rajahalme, J., Särelä, M., Visala, K., & Riihijärvi, J. (2009). Inter-domain rendezvous service architecture PSIRP technical report#TR09-003. Technical report.

49. Kärkkäinen, T., Baig, R., Sathiaseelan, A., Ali, A., Isah, M., Arnal,F., et al. (2017). H2020 RIFE D3.3: Final platform design and setof dissemination strategies. Technical report.

50. Tiso, J. (2011). Designing Cisco network service architectures(ARCH): Developing an optimum design for layer 3 (CCDP).http://www.ciscopress.com/articles/article.asp?p=1763921&seqNum=6.

51. Zhang, N., & Hammainen, H. (2015). Cost efficiency of SDN inLTE-based mobile networks: Case Finland. In 2015 internationalconference and workshops on networked systems (NetSys). IEEE.

52. 3GPP. (2018). TS 29.212 V15.3.0 Policy and Charging Control(PCC). Reference points.

53. Selimi, M., Isah, M., Sathiaseelan, A., Baig, R., Trossen, D.,Krishna, R., et al. (2018).H2020 RIFE D4.3: Final report on tech-nology validation. Technical report.

54. Specification — MulteFire. Retrieved August 17, 2018 fromhttps://www.multefire.org/specification/.

55. Nygren, E., Sun, J., Sitaraman, R. K. R., Sun, J., Sitaraman, R.K. R., & Sun, J. (2010). The Akamai network: A platform forhigh-performance Internet applications. ACM SIGOPS OperatingSystems Review, 44(3), 2–19.

Publisher’s Note Springer Nature remains neutral with regard to juris-dictional claims in published maps and institutional affiliations.

Jaume Benseny is doctoralresearcher in network economicsat the Department of Communi-cations and Networking at AaltoUniversity in Finland. He receivedhis M.Sc. in communicationsecosystem from Aalto Universityin 2016 and his degree in telecom-munications engineering fromTechnical University of Catalo-nia (ETSETB-UPC) in 2006. Inbetween degrees, he worked ati2CAT research center. Hisresearch interests include thetechno-economic scalability of

networking architectures and operator models.

123

https://www.teliacompany.com/en/news/press-releases/2018/7/telia-company-acquires-bonnier-broadcasting/



https://doi.org/10.17487/rfc6826

https://datatracker.ietf.org/doc/html/draft-purkayastha-bier-multicast-http-response-01

https://datatracker.ietf.org/doc/html/draft-purkayastha-bier-multicast-http-response-01

http://www.ciscopress.com/articles/article.asp?p=1763921&seqNum=6

http://www.ciscopress.com/articles/article.asp?p=1763921&seqNum=6

https://www.multefire.org/specification/


Dmitrij Lagutin received the M.Sc.(Tech.) degree from the HelsinkiUniversity of Technology, Finland,in 2005 and the D.Sc. (Tech.)degree from Aalto University, Fin-land, in 2010. He was a Researcherin several research projects withHelsinki University of Technol-ogy and Aalto University, includ-ing EU FP7 PSIRP and PURSUITan EU H2020 POINT projects.He is currently a Coordinator andResearch Fellow in the EU Hori-zon 2020 SOFIE Project, workingat Aalto University, Finland. His

research interests include network security and privacy, Internet ofThings, blockchains, and future network technologies.

Heikki Hämmäinen is Professorof Network Economics at Depart-ment of Communications and Net-working, Aalto University, Fin-land. He has M.Sc. (1984) andPh.D. (1991) in Computer Sci-ence from Helsinki University ofTechnology. His main researchinterests are in techno-economicsand regulation of mobile servicesand networks. Special topicsrecently include measurement andanalysis of mobile usage, valuenetworks of flexible Internetaccess, and diffusion of Internet

protocols in mobile. He is active in several journals and conferenceduties.

Dirk Trossen is a Senior PrincipalEngineer at InterDigital Europe,the European branch of InterDig-ital Inc. His main responsibilitylies in establishing the Europeanpresence of InterDigital throughengagements within the EU-funded Horizon 2020 work pro-gramme as well as within UK-funded efforts. Dirk has more than25 years of experience in net-work architectures, services andwireless technology. He is cur-rently technical leading the Euro-pean efforts FLAME, deploying

and trialing the evolutionary introduction of ICN concepts in upcom-ing 5G networks. He is also an active contributor to European effortsin the 5G(PPP) space through contributions to ETP and 5GPPPwhitepapers. Prior to joining InterDigital, Dirk was co-founder ofTecVis LP, a UK-based software solution company in the mobile,context-aware solution space and he held prior positions as a SeniorResearcher with Cambridge University, Chief Researcher with BTResearch and as a Principal Scientist at Nokia Research. He is alsoa research affiliate with the Advanced Network Architecture groupat MIT CSAIL. He holds a Ph.D. degree in Computer Science fromTechnical University of Aachen, Germany. He published more than 85peer-reviewed papers in international conferences and journals and hascurrently 32 international patents.

123

Documents

Feasibility of IP-over-ICN - Aalto